I’m seeing crashes when using SSL sockets on MacOS 15.
Code that has worked for 10+ years on Mac and PC.
Anyone else experiencing this?
FYI … current available versions of SketchUp do not yet support Sequoia.
A quick websearch …
… and many other articles, such as …
macOS Sequoia Update Causes Issues for Security Tools and VPNs - Techopedia
Apple’s new firewall, a key feature of Sequoia, is suspected to be the root cause. The firewall is intended to enhance security on untrusted networks but has inadvertently blocked essential network functions. Experts have identified issues such as blocked DNS requests and misaligned firewall GUI settings, affecting network-based tools.
2 Likes
The simple line below works.
puts Net::HTTP.get(URI 'https://google.com/')
Note that something is loading net/http, so a require 'net/http' may be needed.
It’s using Ruby’s SSL sockets. Can you be more specific as to what’s failing?
This is a C++ Extension. Very first SSL call crashes on Sequoia - I’ve used this code for 5+ years without issue (on PC as well for what its worth).
SSL_CTX_new(SSLv23_client_method());
I assumed Apple had dropped SSL methods and only supported TLS, but this also crashes now:
SSL_CTX_new(TLS_client_method());
What should I look for?
From your previous message, I assumed as much.
I’m pretty sure the openssl files used by SketchUp (SU) are not ‘Apple’ provided files. They’re built by the SU group.
Five years ago I committed some code similar to:
#ifdef HAVE_TLS_SERVER_METHOD
pCtx = SSL_CTX_new (bIsServer ? TLS_server_method() : TLS_client_method());
#else
pCtx = SSL_CTX_new (bIsServer ? SSLv23_server_method() : SSLv23_client_method());
#endif
Regardless of this issue, you should be doing something like the above. IIRC, the ‘TLS’ methods were added in OpenSSL 1.1.0, and supporting 1.0.2 is a bad idea. But, this is SU, so not sure.
I haven’t tried building/running the repo that contains the above code since I updated to Sequoia.
Does this code run on Windows with SU 2024? I don’t recall having cross-platform problems with OpenSSL. Most of the code I work with is tested on GitHub Actions with Ubuntu, macOS, and Windows. But, on macOS, most are installing packages with brew, including openssl@3. Windows is using MSYS2 or MSFT/vcpkg.
Works fine with SU2024 on Windows.
up until Sequioa it has worked on Mac.
Now I get to this first line of SSL:
Step over it:
Weird… and your comment makes me wonder whether SU team are being bitten by this too?
I just noticed ‘Very first’…
Are you sure you’re using the files provided by SU? I’ve got the following:
2024
libcrypto.3.dylib, libcrypto.dylib
libssl.3.dylib , libssl.dylib
Above seem to be copies, both pairs are the same size?
2022 & 2023
libcryto.1.1.dylib
libssl.1.1.dylib
The simple Ruby code that I posted calls into the Ruby OpenSSL c code that uses:
SSL_CTX_new(TLS_method())
Or, the Ruby code only calls TLS_method(), regardless of whether it’s a client or server connection.
I don’t recall how the three functions (TLS_method(), TLS_client_method(), TLS_server_method()) vary…
Another repo I work with uses TLS_method() for creating a server socket. You might try switching to it, but I suspect the problem is elsewhere.
Using stand-alone Ruby with Sequoia and OpenSSL 3.3.2, and a repo that compiles c code against the OpenSSL files. I installed OpenSSL with brew.
The repo contains the line:
ctx = SSL_CTX_new(TLS_method());
which I changed to:
ctx = SSL_CTX_new(TLS_server_method());
Recompiled, ran all the SSL related tests. It passed.
Not sure what the issue is, but it doesn’t look like it’s OS related.
1 Like
Thanks for the help! Will take another look.
[the copies of libs is likely resolving a softlink in the original install]
And just so I’m clear, thats running inside SU2024, right?
No. I ran up the Ruby Puma web server using stand-alone Ruby.
But, the first message I posted shows that Ruby is creating an SSL Context when making a connection. So, things seem to be working correctly.
The crash you’re getting looks more like a problem with loading the OpenSSL files?
Not sure, and my OS knowledge I’d order as 1) Windows, 2) Linux, 3) macOS. Or, I’m not that familiar with macOS. It’s Linux, but it’s not…
How is your code loading the OpenSSL dylib files? I checked what the SU Ruby is loading:
~ % cd /Applications/SketchUp\ 2024/SketchUp.app/Contents/Frameworks/Ruby.framework/Versions/3.2.2
3.2.2 % objdump -p ruby | grep '@rpath'
name @rpath/libffi.dylib (offset 24)
name @rpath/libssl.3.dylib (offset 24)
name @rpath/libcrypto.3.dylib (offset 24)
Are you able to see if the problem exists with SU 2024 running with Sonoma?
Oh this code has worked fine for years. And certainly on Sonoma last week before I upgraded 
SketchUp uses the Chrome Framework which has always used boringssl.dylib (originally from Google too). Before Mojave, it was totally broken on Mac so I avoid it. However up until Sonoma it worked fine.
I’m presuming Sequoia has switched to newer SSL/TLS and boringssl.dylib in the Chrome Framework used by SU2024 no longer works.
I’ve built universal (x64 + arm64) binaries and linked but for reasons I dont understand the SSL_CTX_new call goes to boringssl.dylib and dies…
I haven’t even looked at what Sequoia natively uses for OpenSSL. SU’s Ruby code uses it’s own OpenSSL dylib files. The switch to OpenSSL 3 came with the update to SU2024, as the original release used version 1.1.1. I think that was mentioned in another thread.
I assumed those were the files you were linking to, not the files used by CEF.
I haven’t looked at boringssl for quite a while…
If your extension is running in the SU process, I would think it would be best to load the files included with SU, not CEF?
EDIT: checked the boringssl docs, and TLS_client_method is deprecated. See BoringSSL - ssl.h
Oh I think Trimble has moved SketchUp to be very very heavily dependent on CEF in the last few years for everything not core CADy stuff.
Anyone on the SU dev team care to chime in?
Trimble has added a warning box to the Hardware and Software Requirements page:
1 Like
I just checked Sequoia
% /usr/bin/openssl version
LibreSSL 3.3.6
Which doesn’t support TLSv1.3. Not sure what Safari, etc use, but I’m sure it supports TLSv1.3.