One TLS for the Whole Machine: What Schannel Is and Who Uses It

When a program on a Windows computer opens a secure web address, the padlock looks the same whether the program is a web browser, a backup tool, a PowerShell script or an artificial intelligence (AI) agent calling a model. Underneath, the work is done in very different places. Many Windows programs do not encrypt anything themselves; they pass the job to a component that ships inside Windows, called Schannel. Others carry their own encryption library and never ask Windows at all. That difference sounds like trivia until the day someone changes a machine-wide security setting, or installs an update, and only some programs on the same computer change their behaviour. This guide explains what Schannel is, how a request reaches it, where the secret keys are kept while it works, which programs follow its rules and which do not, and how anyone can tell the two groups apart, with a closing look at what it means for AI agents running on Windows.

Who does the encryption when a program connects?

Picture a large office building. Some departments employ their own couriers, who pack, seal and deliver every parcel their own way. Most departments, though, simply walk their parcels down to the building's mailroom. The mailroom follows one set of rules, set by building management, and every department that uses it gets those rules automatically. If management decides tomorrow that every parcel must be double-sealed, the mailroom starts double-sealing for everyone, and nobody in the departments has to change a thing. The couriers employed by individual departments, meanwhile, carry on exactly as before, because nobody told them.

A Windows computer works in much the same way when programs open protected connections. The protection itself comes from Transport Layer Security (TLS), the standard behind the padlock in a browser and the s in HTTPS. TLS encrypts what travels over the network and checks that the computer on the other end is who it claims to be. Every program that talks to a secure website, a cloud service or an internal server needs a working TLS implementation, meaning a piece of software that actually carries out those steps.

Windows ships one such implementation as part of the operating system. Its name is Secure Channel, almost always shortened to Schannel. Programs that use Schannel are the departments that use the mailroom: they ask Windows to protect the connection and inherit whatever rules the computer's administrator has set. Programs that bring their own TLS library are the departments with private couriers: they follow the defaults of their own library, and a change to Windows does not reach them.

Nothing on the screen reveals which kind of program you are looking at. A connection from either kind can be perfectly secure, and either kind can be configured badly. The point is not that one approach is better. The point is that a question like 'is TLS 1.0 switched off on this server?' has a different answer for each group, and the people responsible for a machine often assume the answer covers everything that runs on it. The rest of this guide is about knowing which group a program belongs to, and why it matters.

Schannel is a provider behind a common doorway

To see how Schannel fits in, start with how Windows organises security work in general. Windows has a single, shared doorway that programs knock on when they need security services such as proving who they are or protecting a conversation. That doorway is called the Security Support Provider Interface (SSPI). An interface, in software, is an agreed way for one piece of code to ask another for help, like the service window at a bank: you do not need to know how the vault works, only how to fill in the slip.

Behind the doorway sit several specialists, each called a Security Support Provider (SSP). Microsoft's documentation lists the default ones: Kerberos and NTLM, which prove who a user is on a corporate network; Digest; Negotiate, which picks between Kerberos and NTLM; the Credential Security Support Provider (CredSSP), which gives single sign-on to Remote Desktop sessions; and a few more. Schannel is the specialist for TLS and its older relatives, the Secure Sockets Layer (SSL) protocols. On disk it is a single system file, Schannel.dll, in the Windows system folder.

This arrangement explains why Microsoft describes Schannel as needing no setup. There is nothing to install or switch on: Windows ships with it, it supports TLS versions 1.0 through 1.3 plus the datagram variant used for some real-time traffic, and any program that knows how to knock on the SSPI doorway can use it. Most programs do not even knock directly. They use a friendlier helper library that knocks for them, such as WinHTTP (the web library built for Windows services), WinINet (its older sibling for desktop applications) or the networking classes in .NET, Microsoft's application framework.

The result is a stack of layers. A program at the top asks for a connection to an address. A helper library in the middle turns that into an SSPI request. SSPI hands it to Schannel. Schannel runs the TLS conversation with the other computer, and whenever a private key has to be used, the work happens in a protected part of Windows that the program cannot reach. Each layer only needs to know about the one directly below it, which is exactly why a rule set at the Schannel layer affects every program stacked above it.

The private key never visits the program

Every server that accepts TLS connections, and every client that proves its identity with a certificate, owns a private key. A private key is the never-shared member of a key pair: whoever holds it can prove they are the rightful owner of a certificate. If a private key is copied, the copier can impersonate the owner until the certificate is replaced. Where that key lives while TLS is running is therefore one of the most important questions about any TLS implementation.

On Windows the answer is unusual. Windows keeps long-lived private keys entirely outside the memory of the program that relies on them. Microsoft's documentation for Cryptography Next Generation (CNG), the Windows layer that provides cryptographic building blocks, states that such keys are isolated so that they are never present in the application process, and that the Local Security Authority (LSA) process is used as the key isolation process. The LSA is the protected Windows process that also handles sign-in and security policy, and on a running machine it appears as Lsass.exe.

Think of a notary who keeps the official stamp in a locked back room. You hand your document through a window, the notary stamps it out of sight, and you get the stamped document back. You never touch the stamp, so you cannot walk off with it. In the same way, when Schannel needs the private key to prove a server's identity, the request goes through a component called the key storage router to the key isolation service inside the LSA process, the key is used there, and only the result comes back. Microsoft notes that every such access passes through that router and is audited.

Schannel's other working memory lives in the same protected place. Its session cache, which remembers recent connections so that a returning client can skip some of the expensive setup, is held by Lsass.exe; Microsoft's guidance warns that making the cache larger makes that process use more memory. The practical lesson for a newcomer is simple. A Schannel program never needs to be trusted with the raw key, which removes one common way keys leak. It also means that whether a program can use a key depends on Windows permissions, not on the program's own code, a point that becomes very important when services run under their own accounts.

Who inherits the machine's TLS rules

Now for the question that matters most in practice: which programs actually use Schannel? Microsoft's own documentation answers it for the main Windows building blocks, and the pattern is easy to remember. If a program is part of Windows, or is built on a Windows-native networking library, it almost certainly goes through Schannel and therefore inherits the machine's TLS rules.

Start with the web libraries. Microsoft's WinHTTP overview states that the library takes its choice of TLS version from the machine's Schannel configuration. WinHTTP is the library designed for Windows services and background tasks, the kind of software that runs without anyone signed in. WinINet, the library many older desktop applications use, sits on the same foundation. Microsoft's web server, Internet Information Services (IIS), receives its connections through a Windows component called HTTP.sys, and Schannel's own settings page describes options that apply to IIS and to other web services over HTTP.sys, which tells you who is doing their TLS.

Next come the programming frameworks. Microsoft's guidance for the .NET Framework states that it depends on Schannel on Windows, so the operating system dictates which TLS versions can be negotiated and which one is used. Modern .NET follows the same principle: its documentation explains that cryptographic operations are carried out by the operating system's own libraries, which on Windows means Schannel for TLS, while the same .NET program on Linux follows the configuration of the Linux system's OpenSSL library. PowerShell, the Windows command shell and scripting language, is built on .NET, so its web commands travel the same road.

Even the command-line tool many people assume is foreign follows the rule. Windows has shipped its own copy of curl, the popular command-line web tool, since the Windows 10 Insider builds of late 2017. On a Windows 11 computer checked for this guide, running curl.exe with the -V option reported its TLS backend as Schannel. So a curl command typed into a Windows terminal honours the machine's TLS settings, while a copy of curl installed from elsewhere might not, as the next section shows.

The pattern gives you a useful default assumption. Windows features, Windows services, applications written on .NET and PowerShell scripts all inherit the machine's TLS policy without writing a single line of TLS code. That is convenient: one setting protects them all. It is also a responsibility, because the same single setting can hold them all back.

Who brings their own TLS

The second group is just as large and much easier to overlook, because its members look like ordinary Windows programs. They are installed in the usual way, they appear in the Start menu, and they connect to the same websites. But inside, each carries its own TLS library and makes its own decisions.

Google's Chrome browser is the best-known example. Its TLS library is BoringSSL, which its own documentation describes as a fork of OpenSSL designed for Google's needs and used in Chrome and Chromium. Mozilla's Firefox uses its own security libraries, called Network Security Services (NSS). The Python programming language's standard ssl module states that it uses the OpenSSL library, and Node.js, the popular JavaScript runtime, documents its TLS support as built on top of OpenSSL. OpenSSL itself is the open-source TLS library found in a huge amount of server and developer software.

Some programs can go either way. Git, the version-control tool most developers use, has a setting called http.sslBackend whose documented values include openssl and schannel. The same Git on the same computer can therefore follow the machine's Schannel rules on one day and OpenSSL's defaults the next, depending on one line of configuration. That is a good reminder that the question is not only which program, but which program configured in which way.

Microsoft's documentation is explicit about where the machine's rules stop. The page describing Schannel's registry settings states that they govern Schannel alone and leave any third-party TLS implementation installed on the system untouched. So when an administrator turns off an old TLS version for the whole machine, the browser built on BoringSSL, the Python script built on OpenSSL and the Git client pointed at OpenSSL are all untouched. Each continues to do whatever its own library allows by default.

This is what it means to say that one Windows machine can have several TLS policies at once. There is the Schannel policy, shared by every program in the first group, and then a separate policy inside every program in the second group, each set by a different organisation on a different release schedule. None of them is wrong. They simply have to be checked separately.

Shared fate: one update, every Schannel program

Because so many programs share Schannel, they also share its fate. When Windows improves, every Schannel program improves at the same moment, often without the program's authors doing anything at all. When something goes wrong in Schannel, every Schannel program is affected at the same moment too. Both halves of that sentence are worth understanding.

The good half is easy to see in the history of TLS 1.3, the newest version of the protocol. Microsoft's table of protocol support shows TLS 1.3 arriving, switched on for both clients and servers, with Windows 11 and Windows Server 2022; every version of Windows 10 lists it as not supported. A .NET Framework application that lets the operating system choose therefore behaves differently depending on where it runs, and Microsoft's own guide gives the example directly: such an application uses TLS 1.2 on Windows 10 and TLS 1.3 on Windows 11. The application did not change. The machine did, and the application inherited the upgrade.

The harder half showed up in November 2014, when Microsoft published security bulletin MS14-066 for a flaw in Schannel tracked as CVE-2014-6321. The update was rated Critical for all supported releases of Windows, and it fixed the problem by correcting how Schannel handled specially crafted network packets. The useful lesson here is not the details of the flaw. It is that a single component sat underneath a very large number of services, so a single update had to reach all of them, and until it did, all of them shared the exposure.

Shared fate also shapes how settings behave. Microsoft documents that a program calling Schannel can restrict the TLS versions it is willing to use, but cannot expand them beyond what the machine allows. A machine-wide restriction is therefore a hard floor that no Schannel program can climb back under. And because programs tend to reuse their TLS setup across many connections for speed, Microsoft notes that a settings change may only take effect after the program or service is restarted. For anyone responsible for a server, that combination means changes are powerful, broad and sometimes slow to appear.

None of this makes one camp automatically safer than the other. Programs that carry their own library also share a fate, just a different one: when a flaw is found in OpenSSL or BoringSSL, every program carrying that library needs its own update, delivered on its own maker's schedule, and a computer can end up with several copies at several patch levels. Schannel concentrates the work in one place, Windows Update, while bring-your-own libraries spread it across every vendor. Knowing which camp each program is in tells you whose update you are waiting for.

How to tell which camp a program is in

Since nothing on the screen gives the answer away, how does anyone find out whether a given program uses Schannel? There is no single switch to flip, but a short series of questions settles it for almost every case, and none of them requires changing anything on the machine.

First, ask what the program is built on. If it is part of Windows, a Windows service, or an application written with .NET or PowerShell, start from the assumption that it uses Schannel, because that is what the documentation for those foundations says. If it is written in Python, Node.js, Java, Go or another language that ships its own networking stack, or if it is a browser such as Chrome or Firefox, start from the opposite assumption.

Second, ask the program itself. Many command-line tools will tell you which TLS library they were built with if you ask for their version details. The copy of curl that ships with Windows prints Schannel; a copy built against OpenSSL prints OpenSSL and its version number. A Python interpreter will print the exact OpenSSL release it is linked to. Git will tell you whether its backend setting has been changed.

Third, check the documentation for settings the program honours. Software that relies on Schannel usually tells administrators to manage TLS through Windows itself. Software that brings its own library usually documents its own configuration file, environment variable or policy setting instead. If the vendor's guide never mentions Windows TLS settings at all, that is a strong hint.

Here is how the questions play out on one ordinary server. It hosts a small website on IIS, runs a nightly PowerShell report that uploads a file to a cloud storage service, and runs a Python agent that calls a language model. The administrator applies a policy that retires an old TLS version across the machine. The website is affected, because IIS receives its connections through Schannel. The PowerShell report is affected, because PowerShell runs on .NET, which uses the operating system's TLS. The Python agent is not affected at all, because its connections are made by OpenSSL. One change, one machine, two different outcomes, and only careful questions reveal it.

Finally, when the answer still is not clear, treat the program as its own policy until proven otherwise. The costly mistake is not checking too much; it is assuming that a machine-wide setting covers a program that never reads it.

# Windows' own curl: the version line names its TLS backend
curl.exe -V

# Python: prints the OpenSSL release its ssl module is linked to
py -c "import ssl; print(ssl.OPENSSL_VERSION)"

# Git: shows the TLS backend if one has been chosen (no output means the default)
git config --get http.sslBackend

The agent's runtime, not the server, sets its TLS rules

Put simply, an AI agent is software in which a large language model (LLM), a text-generating AI system, chooses the next step and then reaches out to tools to carry it out. Each of those steps is a network connection: a call to the model's service, a call to a search tool, a call to an internal database or a server speaking the Model Context Protocol (MCP), an open protocol that lets agents discover and call tools. Every one of those connections is protected by TLS, and every one is carried out by whichever TLS implementation the agent's runtime uses.

That makes the camp question very concrete. An agent written in C# on .NET, or as a PowerShell script, running on Windows, inherits the machine's TLS policy automatically. If the security team has retired old TLS versions on that server, the agent cannot use them, whether or not its developers ever thought about it. Rewrite the same agent in Python or Node.js, run it on the same server, and the picture changes completely: the agent now follows the defaults of the OpenSSL library it ships with, and the machine's carefully managed Schannel settings no longer apply to it.

Neither choice is wrong, and a Python agent can be every bit as well protected. What goes wrong is the assumption. A compliance report that says 'this server only allows modern TLS' is a statement about Schannel. It is silent about the agent's own runtime, and agents are increasingly the programs on a server making the most outbound connections.

Real deployments are rarely one runtime from end to end. A common pattern is an orchestrator written in .NET that hands work to a tool server written in Python, which in turn calls a database driver written in something else again. Each hop in that chain is a separate TLS connection with its own client and its own server, and each end of each hop is decided by its own runtime. So the honest answer to 'what TLS does our agent use?' is usually a short table, one row per hop, rather than a single sentence.

For people who run agents in production, a few habits close that gap without much effort. They also give leaders a straight answer when someone asks whether the organisation's TLS rules really cover its AI workloads, which is a question worth being able to answer with evidence rather than hope.

1. For every agent, record the runtime and TLS library it actually uses, not just the host it runs on.
2. Treat Schannel-based agents as covered by machine policy, and verify that policy once per server image.
3. Treat agents on their own libraries as separate policies, and pin or review their library versions like any other dependency.
4. Prefer letting the runtime choose the TLS version over hard-coding one, so the agent benefits when the platform improves.
5. Log the TLS version each outbound connection actually negotiated, so a silent difference between camps shows up in the data.

Glossary

Transport Layer Security (TLS)

The standard that encrypts network connections and checks the identity of the computer on the other end; it is behind the padlock in HTTPS.

Schannel

Short for Secure Channel, the component built into Windows that carries out TLS for programs that ask Windows to protect a connection.

Security Support Provider Interface (SSPI)

The shared doorway Windows programs use to request security services such as authentication and protected connections.

Security Support Provider (SSP)

One specialist behind the SSPI doorway; Schannel is the provider for TLS, while Kerberos and NTLM handle sign-in.

Local Security Authority (LSA)

A protected Windows process, Lsass.exe, that handles sign-in and security policy and keeps private keys isolated from programs.

Private key

The never-shared member of a key pair, which proves ownership of a certificate; whoever copies it can impersonate the owner.

WinHTTP

A Windows web library designed for services that run without a signed-in user; it follows the machine's Schannel settings.

OpenSSL

A widely used open-source TLS library; Python, Node.js and many other tools use it instead of Schannel.

AI agent

Software in which a language model picks each next step and network calls to tools and services carry it out.

Further reading

1. TLS/SSL overview (Schannel SSP) (Microsoft Learn)
2. Security Support Provider Interface Architecture (Microsoft Learn)
3. Transport Layer Security (TLS) registry settings (Microsoft Learn)
4. About WinHTTP (Microsoft Learn)
5. Transport Layer Security (TLS) best practices with .NET Framework (Microsoft Learn)
6. Key Storage and Retrieval (Microsoft Learn)
7. Microsoft Security Bulletin MS14-066 (Microsoft Learn)