We are releasing compiled versions of OpenSSL 4.1.0 Alpha 1. This is a prerelease from the OpenSSL Developers.
Since this version is a prerelease, it will only be available temporarily until a new release is made and there is no automated installer for them.
We make this version available for users that want to test it. We do NOT recommend using this in production software.
We have published a console demonstration showcasing the core TaurusTLS 2.0 Client SSL Socket architecture. This sample illustrates the low-level socket state machine, immutable configuration snapshots (ITaurusTLSSslSocketCtx), and the fluent context builder pattern.
The demo covers multiple client operational modes, including direct IP connections (csmDisabled), standard SNI (csmStandardSNI), ECH GREASE anti-ossification (csmECHGrease), dynamic ECH key discovery with automated reconnection (csmECHGreaseDiscovery), and private ECH with suppressed outer SNI (csmECHNoOuter). Native Windows Certificate Store integration (UseSystemCertStore) and custom CA chaining are also demonstrated.
While high-level IOHandler integration remains in progress, this sample models the exact lifecycle operations executed under the hood. The demo source code is available in the demos\TaurusTLS_2\HTTPCLi path on the TaurusTLS2.0-@AT branch.
We are pleased to announce the release of TaurusTLS 1.0.11.53. This maintenance release addresses several bugs, including:
SSL_CTX_set_ciphersuites)
This release features a new property, CipherSuites that is used to specify the cipher suites you wish to use with TLS 1.3. Do not confuse this with the CipherList property which specifies the ciphers you wish to use with TLS 1.2 or earlier.
OpenSSL 3.0 has reached it's end-of-life (EOL) meaning there will be no further public releases. We discourage users from continuing to use this version. You have the following options:
For further information, please consult the OpenSSL Roadmap.
We recommend that developers upgrade to OpenSSL 4.0 and eventually to OpenSSL 4.2 when it is released because OpenSSL 4.2.x will have long-term-support. The OpenSSL 4.x versions are recommended because TaurusTLS 2.0 will feature Encrypted Client Hello (ECH) including GREASE (Generate Random Extensions And Sustain Extensibility).
We are excited to announce the release of official Windows Installer (MSI) packages for OpenSSL 3.0.22, 3.4.7, 3.5.8, 3.6.4, and 4.0.2 across x64, x86, and arm64 architectures.
Built with WiX Toolset v5 and digitally signed with Azure Trusted Signing, these packages are ready for enterprise deployment (GPO, Intune, SCCM) and feature automatic rollback on failure, on-demand repair, and optional 32-bit runtime compatibility on 64-bit Windows.
Download the new MSI installers on our OpenSSL Distribution Releases page.
We are excited to announce the release of unified ARM64X OpenSSL binaries for Windows on ARM, officially replacing our previous standalone arm64ec packages.
By leveraging Microsoft's ARM64X format, these binaries fuse Native ARM64 and ARM64EC into single dual-architecture binaries. This means the exact same DLLs and import libraries work seamlessly for both native ARM64 executables and ARM64EC applications, including those compiled with Embarcadero RAD Studio (Delphi / C++Builder).
All binaries are built with HybridCRT (eliminating external vcruntime140.dll dependencies) and are digitally signed with Microsoft Azure Trusted Signing.
The new binaries and installers are now available for download on our OpenSSL Distribution Releases page.
The OpenSSL project has released updated versions of its core library (3.0.22, 3.4.7, 3.5.8, 3.6.4, and 4.0.2). Thanks to our automated build pipeline, these updates have already been compiled, packaged, and made available in all supported formats across our target platforms.
The new binaries are now available for download on our OpenSSL Release Distribution page.
As these updates contain important security patches, we highly recommend updating your software distributions with these latest binaries at your earliest convenience to ensure continued security and stability.
We are always excited to see how TaurusTLS is being utilized in the wild. If you have developed or released an application—whether it is commercial, freeware, or open source — that relies on TaurusTLS, we would love to hear about it!
By sharing your project, you help us demonstrate the library's real-world impact and guide our future development. We would be proud to feature your product on our official Showcase of TaurusTLS-Powered Products page.
Please let us know about your software by opening a feedback thread on our GitHub Show and Tell Discussion Forum or by reaching out to us directly through our Contact Us form.
We are pleased to announce that official Windows installers for our OpenSSL distribution are now available for download. These installers bundle our pre-compiled libraries for x86, x64, and ARM64EC architectures.
To accommodate different deployment scenarios and developer workflows, we have prepared two distinct installer formats:
.msix packages that provides a seamless, one-click installation experience optimized for Universal Windows Platform (UWP) applications.Both kinds of installer packages are fully digitally signed under the name "J. Peter Mugaas" using our Individual Validation (IV) Code Signing Certificate, ensuring secure, tamper-free delivery and a smoother installation process on Windows systems.
We are pleased to announce that starting today, our distributed OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21 DLLs and the openssl.exe executable are officially code-signed under the name "J. Peter Mugaas".
This digital signature ensures the integrity and authenticity of the binaries, verifying that they have not been altered or tampered with since compilation. Additionally, code-signing should help reduce false-positive warnings from antivirus software and Windows SmartScreen during installation.
We highly recommend updating your software distributions with these newly signed files.
The OpenSSL context (SSL_CTX) and connection (SSL) structures rely on Public Key Infrastructure (PKI) objects—such as certificates, public and private keys, CRLs (Certificate Revocation Lists), and Diffie-Hellman (DH) or Elliptic Curve (EC) parameters—to establish secure communications. These PKI objects can be packaged in various formats, including Base64-encoded PEM files, raw binary DER files, or PKCS#12 containers. Each format has its own distinct structure, encoding scheme, and internal encryption mechanisms.
Historically, OpenSSL implemented distinct sets of routines tailored to each specific format. This introduces significant challenges for developers who need to support multiple PKI formats in their applications, as these legacy routines feature divergent parameter signatures and inconsistent usage patterns. To address this, OpenSSL introduced the OSSL_STORE API in version 1.1.1, which became fully production-ready in OpenSSL 3.0. This API offers a unified interface capable of processing all major PKI formats under a single, cohesive framework.
IOHandler instances use a reactive loading pattern, resolving PKI objects on demand. For example, a server-side SSL socket reloads the certificate and private key files on every incoming client connection. This results in redundant disk I/O operations and reduces connection throughput (Connections Per Minute / CPM).OSSL_STORE Wrapper Improves Usability and PerformanceThe OSSL_STORE API unifies the loading of various PKI formats into a single, cohesive interface. It can ingest data in single or multiple passes and automatically instantiate native OpenSSL types such as X509 (certificates) and EVP_PKEY (private/public keys). Crucially, the same wrappers can be used for in-memory buffers, offering developers unprecedented flexibility.
TaurusTLS 2.0 leverages these wrappers to support several advanced integration scenarios:
IOHandler instances. This will be exposed via a new Trusted Store component.Both approaches will significantly simplify code maintenance and improve overall runtime performance.
The initial implementation of these OSSL_STORE wrappers is available for review in our Development Branch.
We are pleased to announce the release of TaurusTLS 1.0.10.52. This maintenance release addresses several bugs, including:
As previously discussed, this release significantly improves compatibility for C++Builder developers.
Recently, we resolved an issue that affected the behavior of TaurusTLSIOHandlerSocket under poor network conditions on POSIX systems. See Issue #251 (Strange client issue). This fix prompted us to review OpenSSL and TCP socket interoperability in TaurusTLS 2.0.
We found that OpenSSL enables SSL_MODE_AUTO_RETRY by default. In this mode, OpenSSL prevents read and write operations from returning control to the application while it processes the transmission of internal protocol messages. It only yields control once it has successfully decoded application data records, or when application records are encoded and sent successfully.
However, the SSL/TLS protocols rely on internal control frames—which can be transmitted in the middle of application data—to maintain connection integrity. Losing one or more of these control frames can delay read/write operations and directly impact the responsiveness of TaurusTLSIOHandlerSocket. To improve stability under unstable network conditions, the TaurusTLS team plans to disable SSL_MODE_AUTO_RETRY in TaurusTLS 2.0.
We are currently evaluating the implementation complexity and the robust error handling required for this approach.
Stay tuned for more updates.
There is an unsung hero in the TaurusTLS distribution that is not given enough credit. That unsung hero is the TaurusFTP Console Demo program that is included with TaurusTLS distributions in the /Demos/TaurusFTPConsole folder. This is not merely a simple demo program, but rather a fully functional console FTP (File Transfer Protocol) client that is completely driven by commands. I consider this program superior to the bundled FTP client included in Windows because:
AUTH TLS command, the server sends a response, and TLS negotiation begins. In implicit TLS, the connection is made to port 990 and TLS negotiation happens immediately.
MODE Z if the server supports this.
PASV) by default instead of relying on active transfers (PORT). Passive transfers tend to be more friendly in firewall/proxy configurations and NATs (Network Address Translators) than active transfers because the PASV response is an IP address and port that the server is listening on. In active transfers, an IP address and port number is sent by the client and the IP address might be local network instead of the Internet.EPSV and EPRT commands that allow the client and server to communicate IPv6 addresses as defined by RFC 2428: FTP Extensions for IPv6 and NATs.
MLSD command which provides a standardized machine and human-readable directory listing format as specified by RFC 3659: Extensions to FTP by default instead of simply using the old standard DIR command which does not specify a format (although the Unix format is a de facto standard).
Using the program is very simple. The program provides a help command that lists the commands and what they do. In addition, you can use the help command function to get help with the command parameters.
I have checked in extensive modifications to make TaurusTLS compatible with C++Builder. This resolves issue #241 (error when compiling under C++Builder). These changes will be available in the next release of TaurusTLS.
While we still do not formally support C++Builder due to a lack of dedicated expertise and resources, we are pleased that this update significantly improves the situation for C++Builder developers.
We are releasing TaurusTLS 1.0.9.51. This fixes several bugs including:
This release supports bidirectional shutdown through the property UseBidirectionalShutdown.
This release is dedicated to my late father, John N. Mugaas, PhD. who died June 27, 2026. RIP.
We are excited to share that TaurusTLS 2.0 client (xxxIOHandlerSocket) and server (xxxServerIOHandler) components will feature support for the Encrypted Client Hello (ECH) TLS extension. This critical addition will help protect user privacy by minimizing the metadata exposed during the initial TLS handshake.
Our integration of ECH in the initial release of TaurusTLS 2.0 will work as follows:
ECHConfig values via DNS or DNS-over-HTTPS (DoH) queries out-of-the-box on the client side (xxxIOHandlerSocket).xxxServerIOHandler), there will be no built-in mechanism to dynamically update DNS SVCB or HTTPS resource records with updated ECHConfig parameters.To further enhance client privacy, we are also implementing the ECH GREASE (Generate Random Extensions And Sustain Extensibility) mechanism. This allows your client applications to safely send dummy ECH extensions to prevent network fingerprinting, even if an ECHConfig payload is not yet known (provided the destination server supports GREASE).
Stay tuned for more updates as development progresses!
The TaurusTLS development team is pleased to announce the launch of a major modernization project for our library, currently codenamed TaurusTLS 2.0.
Our primary goals for this next-generation release include:
Unfortunately, achieving these modernization goals means we will not be able to maintain full backward compatibility with older TaurusTLS components. We sincerely apologize for any inconvenience this may cause.
To ensure a smooth transition, we plan to maintain and support both the current TaurusTLS branch and the new TaurusTLS 2.0 branch in parallel for a reasonable timeframe. This will give you ample time to migrate and adapt your existing applications.
We highly value your feedback and feature requests as we shape TaurusTLS 2.0. Please let us know your thoughts directly on our issue tracker!
We are saddened to announce that we are officially dropping support for C++Builder. Unfortunately, we do not have the specialized expertise or resources required to properly address and resolve C++Builder-specific issues. To ensure the highest quality for our core users, we have decided to focus our efforts entirely on supporting Delphi.
However, if you have strong C++Builder expertise and are interested in helping maintain or resolve issues for this platform, we would highly welcome your contributions.
TaurusTLS has a new website. It took several days of coffee-fueled benders to do this. My goals for this website is make information available about TaurusTLS to the people that need it. This involves handicapped accessibility (an extremely personal thing for me), ability to work on mobile devices, and the ability to print the content of this site. This involved a lot of research and testing. The website is completely done by hand using tools such as CSE-Validator, Total Validator, some online tools, and of course, Google.
I need to thank David Nottage for helping me with the CSS. He did a much better job than I could.