Re: OpenSSL 1.1.1 Windows dependencies
On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote: > > That was my initial thought too, except that if it were > > firewall-related, the initial port 587 connection would be blocked, > > and it isn't - the failure doesn't happen until after STARTTLS has > > been issued. > > Not necessarily. That's true for a first-generation port-blocking > firewall, but not for a packet-inspecting one. There are organizations > which use packet-inspecting firewalls to block STARTTLS because they > enforce their own TLS termination, in order to inspect all incoming > traffic for malicious content and outgoing traffic for exfiltration. I now have wireshark captures showing the exchanges between the working instance and the non-working instance respectively; the problem is definitely happening after STARTTLS has been issued and during the TLS handshake. I'm not high-level enough to be able to make any sense of the negotiation data though. The wireshark capture is quite short (22 items in the list) and I don't mind making it available if it would be useful to anyone. > > Furthermore, the OpenSSL > > configuration is identical between the systems/combinations of > > OpenSSL that work and those that don't. > > Do you know that for certain? There's no openssl.cnf from some other > source being picked up on the non-working system? I'm pretty certain, but I'll get the customer to double-check. Cheers! -- David --
Re: OpenSSL 1.1.1 Windows dependencies
On 21 Oct 2022 at 7:27, Richard Levitte wrote: > Let me ask you this: on what Windows version was your application > built? Common wisdom would be to build on the oldest version... My application is a very traditional Win32 application, and at the moment (and until circumstances *force* me to change) I build it in a Windows 7 SP2 VM. There's really no build-related reason why it shouldn't work on Server 2012, especially since the 1.1.1g build (which DOES work on the affected system) is built in exactly the same VM. It's a puzzle, for sure. Thanks for taking the time to look into this for me Richard. Cheers! -- David --
Re: OpenSSL 1.1.1 Windows dependencies
On 20 Oct 2022 at 20:04, Michael Wojcik wrote: > 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. For a variety of reasons to do with redistributables, I build OpenSSL as no-shared, and because of the compiler I prefer to use (an older build of Visual C), I have to compile with no-capi as well, so CAPI clearly isn't an issue in this case. But to be sure, I tried rebuilding OpenSSL with Visual C 2022 (using Visual C 2019 as the compile unit) and according to the customer, the result was the same. > 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. That was my initial thought too, except that if it were firewall-related, the initial port 587 connection would be blocked, and it isn't - the failure doesn't happen until after STARTTLS has been issued. Furthermore, the OpenSSL configuration is identical between the systems/combinations of OpenSSL that work and those that don't. > 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. Unfortunately, I don't have that level of access to the customer's systems. I was really just wondering if the combination of factors rang any bells with anyone before I started digging much deeper; it's altogether possible that I might just have to write this one off to experience and tell the user to use a 1.1.1g build of OpenSSL (which I build exactly the same way, and which works correctly in the same setup). Thanks for the help - appreciated. Cheers! -- David --
OpenSSL 1.1.1 Windows dependencies
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 --
NASM virus issues.
I normally compile OpenSSL with "no-asm", but this time I thought I'd try installing NASM and seeing what difference, if any, it actually made. I downloaded NASM from the official site (which I believe to be http://www.nasm.us) and, as I always do with anything I source from outside my firewall, ran it through virustotal (https://www.virustotal.com/gui/home/upload). It reports 11 different scanners out of 72 finding malware in the file (nasm-2.15.01-installer-x86.exe). Now, one or two reports from Virustotal is normal - there are so many scanners out there that there are bound to be occasional false-positives... But 11 is more than I have ever seen on something that supposedly wasn't infected. Interestingly, VirusTotal did not have cached results for this file, meaning that nobody else has tested it in the last month or so. Google didn't reveal any insight, and the NASM project doesn't have any contact options that don't involve registration or mailing lists or I'd report this to them. There is no mention of anything like this in their forum. 11 reports is too many for me to feel safe using this product, so for now I'll keep using no-asm, and hope that it's not going to get more deprecated than it apparently is at present (based on the comments in INSTALL). If anyone on the list has a NASM account or knows any of the maintainers, could they pass this on? They really should be aware of it. Cheers! -- David --
Re: OpenSSL 1.1.1g test failures
On 26 Jun 2020 at 11:55, Matt Caswell wrote: > No - this is not normal output. We would expect the self tests to pass > on Windows > > The ONLY > > non-standard thing I do is change the /MD switch (link to the DLL > > versions of the runtime libraries) to /MT (static link the runtimes) > > because I don't want to have external dependencies in my production > > environments > > How exactly do you make this change? By editing the Makefile? Have you > tried it without doing this? My guess is that this is exactly the > cause of the problem. AppLink is all about dealing with differences in > MS runtimes. Assumption, as they say, is the mother of all fu??ups... In this case, the failed assumption was that a non-standard modification I had been making for many years would continue to work simply because it had in the past. Matt is, of course, quite right. When I changed the "/MT" back to "/MD" in CNF_CFLAGS and rebuilt everything, it all worked like clockwork. My thanks to you Matt - you've solved my problem. Is there a standard (i.e, approved) way of using the static RTLs instead of the DLL ones? Or is my only option to modify the applink code so that it checks its environment in a different way? The problem with the dynamic RTLs is that my application is often used in environments where the user may not have sufficient rights to install the redistributables - whereas, if I use the static versions, the code is a little bigger, but there's no redistributable installation required and I never run into rights issues. Again, thank you for the assistance, Matt - I appreciate it. Cheers! -- David --
OpenSSL 1.1.1g test failures
Environment: Windows 7 (I know, I know - I just hate Windows 10). Compiler: Visual Studio, have tried both VS2008 Pro and VS2019 Pro OpenSSL Build: 1.1.1g, retrieved from OpenSSL.org last night I've been attempting to build OpenSSL 1.1.x since it came out, but each time I do so, I find that, while it compiles and links cleanly, it fails about 50% of its self tests when I perform "nmake test". It has been this way for several releases. By "fail" I mean that there's a stream of "dubious..." outputs that look like this excerpt: -- Cut here ... test\recipes\03-test_internal_siphash.t . ok test\recipes\03-test_internal_sm2.t . ok test\recipes\03-test_internal_sm4.t . ok test\recipes\03-test_internal_ssl_cert_table.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests test\recipes\03-test_internal_x509.t ok test\recipes\03-test_ui.t ... ok test\recipes\04-test_asn1_decode.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests test\recipes\04-test_asn1_encode.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests ... -- Cut here Each time I went through the process, I saw the long string of self-test failures and decided I'd put off migrating to 1.1.1 until it was sorted out, but it's been the same for at least four releases now. I finally decided I needed to track down what was going on, so I extrapolated how to run the failing tests manually with more verbose output from the OpenSSL wiki pages (which are just a little out of date). It appears that for at least the first twenty or thirty of these failures, the reason is because the test application has been compiled without including the required Applink code - a verbose output typically looks like this: -- Cut here O:\ >perl test\recipes\05-test_idea.t 1..1 OPENSSL_Uplink(5C790330,08): no OPENSSL_Applink ..\ideatest.exe => 1 not ok 1 - running ideatest # Failed test 'running ideatest' # at util/perl/OpenSSL/Test/Simple.pm line 77. # Looks like you failed 1 test of 1. -- Cut here Is this just the way it is? I would have thought that 50% self-test failure would be ringing alarm bells everywhere if it were common, so I can only conclude that there's something odd about my environment, or that I'm doing something wrong, but this is about as vanilla a build process as I can possibly make it. I follow the steps for Win32 in INSTALL, and as I said at the start of this message, the nmake process goes cleanly, not a single warning or error. The ONLY non-standard thing I do is change the /MD switch (link to the DLL versions of the runtime libraries) to /MT (static link the runtimes) because I don't want to have external dependencies in my production environments (I lived in "DLL Hell" for so long that I'm now quite paranoid about that). This change has never caused problems in the past, and doesn't seem to be relevant to the problems I'm seeing. I've been building OpenSSL myself for a number of years, most recently with the end-of-life v1.0.2 builds, which always go without a hitch. As I remarked, I've been putting off moving to v1.1.1 because I'm so uneasy about these self-test failures, but I can't continue doing that any longer as TLS3 starts coming on stream. Anyone have any insights into what I'm doing wrong, or what I can do about this? I'm very reluctant to use the software in production if it can't pass its own self-test regime, even if it appears to work normally otherwise. Comments most welcome. Cheers! -- David --
