MENU
  1. Inicio
  2. C#
  3. Cómo usar SslStream con OpenSSL en Windows: guía completa

Cómo usar SslStream con OpenSSL en Windows: guía completa

C#

¿Necesitas funciones avanzadas de OpenSSL en tu aplicación .NET pero te encuentras con que SslStream usa, en Windows, la pila nativa Schannel? Este artículo explica por qué ocurre, qué implicaciones tiene y cómo puedes construir o integrar un backend basado en OpenSSL manteniendo la ergonomía de la plataforma.

Índice

Resumen de la pregunta

El objetivo es forzar a SslStream a operar sobre OpenSSL en Windows, sustituyendo a Schannel. La respuesta corta es: hoy no existe ningún conmutador ni API oficial que lo permita. Para lograrlo tendrás que abstraer la capa TLS por tu cuenta o recurrir a bibliotecas de terceros.

Comportamiento predeterminado de SslStream

SslStream actúa como un envoltorio de alto nivel que abstrae el canal TLS. En tiempo de ejecución delega todo el trabajo de cifrado al sistema operativo:

  • Windows →  usa Schannel (Security Support Provider Interface TLS/SSL).
  • Linux / macOS →  normalmente usa OpenSSL o la variante que distribuya la distro.

El motivo es pragmático: de este modo .NET aprovecha las optimizaciones de la plataforma, las actualizaciones de seguridad automáticas y la integración con el almacén de certificados del sistema.

¿Por qué no se puede cambiar el backend con una propiedad?

La pila TLS no es un mero plugin. Forma parte de la ABI del sistema operativo y se encarga de temas tan delicados como:

  • Acceso unificado a todo el almacén de certificados (personales, CA intermedias, raíz, revocación, Smart Cards…).
  • Cumplimiento de políticas de grupo y estándares (FIPS 140‑2, Suite‑B, directivas corporativas).
  • Compatibilidad binaria con kernel‑mode (por ejemplo, TLS 1.3 para HTTP/2 en Kernel Mode).

Desacoplar esta responsabilidad exigiría reescribir grandes trozos de la BCL o, como mínimo, duplicar el código nativo para cada backend, algo que el equipo de .NET nunca ha considerado sostenible.

Tabla de aspectos clave

AspectoDetalles clave
Comportamiento predeterminadoSslStream delega el cifrado al SO. En Windows → Schannel; en Linux/macOS → OpenSSL.
Cambio de backendNo hay API nativa para sustituir Schannel por OpenSSL.
Alternativas viables1. Desarrollar un envoltorio propio (C/C++ → P/Invoke).
2. Usar bibliotecas de terceros: OpenSSL.NET, Bouncy Castle, frameworks con motor TLS propio.
Ventajas de OpenSSLControl total de versiones/extensiones; acceso a ciphers o modos experimentales.
Desventajas y riesgosMás complejidad, actualizaciones manuales, pérdida de integración con directivas de Windows, posibles problemas de interoperabilidad.
Conclusión prácticaNo hay “interruptor OpenSSL”. Es necesario encapsular o integrar una solución externa.

Alternativa 1 – Construir tu propio stream basado en OpenSSL

1  Decidir la estrategia de interoperabilidad

En .NET existen dos caminos:

  • P/Invoke puro (DllImport) → idéntico rendimiento callsite pero verbosidad elevada.
  • C++/CLI → permite invocar API nativas con sintaxis .NET friendly y crear managed wrappers en un único binario.

2  Seleccionar las partes de OpenSSL necesarias

Casi siempre bastan libssl (protocolo) y libcrypto (primitivas). Compilar estático reduce dependencias, pero aumenta el tamaño del binario. Compilar dinámico facilita los parches de seguridad:

# Configure estático (Win64, Release)
perl Configure VC-WIN64A no-shared no-ui-console enable-tls1_3 --prefix=C:\OpenSSL-Static
nmake install

3  Crear un contrato gestionado

Define una interfaz que replique los métodos esenciales de SslStream para que el resto de tu aplicación siga intacta:

public interface ITlsStream : IDisposable
{
    Task AuthenticateAsClientAsync(string host, X509CertificateCollection certs,
                                   SslProtocols protocols, bool checkRevocation);
    int Read(byte[] buffer, int offset, int count);
    void Write(ReadOnlySpan<byte> buffer);
    void Close();
}

4  Implementar el puente nativo

Ejemplo de inicialización mínima vía P/Invoke:

[DllImport("libssl", CallingConvention = CallingConvention.Cdecl)]
private static extern IntPtr SSL_new(IntPtr ctx);

\[DllImport("libssl", CallingConvention = CallingConvention.Cdecl)]
private static extern int SSL\_connect(IntPtr ssl);

// ...
\ssl = SSL\new(\_ctx);
var ret = SSL\connect(\ssl);
if (ret <= 0) throw new TlsException(GetError());

5  Integrar con el socket

OpenSSL requiere callbacks de lectura/escritura sobre el manejador de Socket. Lo habitual es asignar el SafeHandle del descriptor y luego delegar a SSLread/SSLwrite.

6  Empaquetar y distribuir

Coloca los DLLs compilados en la misma carpeta que el ejecutable o usa runtime identifiers para NuGet (runtimes/win-x64/native/). Configura DllImportSearchPath para reducir ataques de DLL hijacking.

Alternativa 2 – Bibliotecas de terceros

OpenSSL.NET

Un wrapper gestionado veterano que expone gran parte de la API C. Ventaja: ya hace el P/Invoke duro. Inconveniente: interfaz poco idiomática y mantenimiento irregular; tendrás que parchear tú mismo para TLS 1.3.

Bouncy Castle

Implementación 100 % C# de TLS y criptografía. No depende de binarios nativos, por lo que simplifica la distribución. En contra, el rendimiento suele ser inferior a OpenSSL y no aprovecha AES‑NI de forma tan directa. Aun así, es muy valorada cuando se busca portabilidad pura o se necesita extender el protocolo.

Frameworks con TLS propio

gRPC, MQTTnet, OpenSearch .NET Client y algunos motores de alto rendimiento (p. ej., kestrel modificado) ya permiten compilar toda la pila sobre OpenSSL en todas las plataformas, eliminando las diferencias de comportamiento.

Ventajas reales de migrar a OpenSSL

  • Versiones de protocolo: habilitar TLS 1.3 temprano, 0‑RTT, PSK, QUIC, etc.
  • Cifrades exóticos: ChaCha20‑Poly1305, Curve448, Brainpool, suites post‑cuánticas experimentales.
  • Control granular de extensiones ALPN, GREASE, OCSP stapling, recordsizelimit.
  • Parcheo rápido: no dependes de Windows Update para cerrar CVEs.

Desventajas y riesgos

Mantenimiento continuo — OpenSSL publica parches críticos cuatro veces por año. Debes monitorizar CVEs, recompilar y redistribuir. Además:

  • Pierdes la integración nativa con certificados de usuario, DirectAccess, credenciales de tarjeta inteligente.
  • Si tu organización exige FIPS 140‑2, debes compilar la rama openssl-fips y pasar el SelfTest en cada arranque.
  • Mayor superficie de errores: memory safety, fugas de descriptor, doble free, etc.
  • Duplicas el consumo de memoria al cargar simultáneamente Schannel y OpenSSL.

Impacto en el rendimiento

En sistemas modernos, Schannel y OpenSSL alcanzan velocidades similares usando AES‑GCM con AES‑NI. Las diferencias aparecen en:

  • Procesos con handshakes recurrentes: OpenSSL permite session tickets más agresivos.
  • Escenarios de transferencia de muchos pequeños fragmentos: el record size en OpenSSL se puede ajustar dinámicamente.
  • Entornos de baja latencia (finanzas, juegos en la nube): OpenSSL ofrece APIs para 0‑RTT y ajustes de congestion control en QUIC.

Buenas prácticas de implementación

  1. Automatiza el pipeline CI/CD para compilar OpenSSL y lanzar unit tests que verifiquen renegociaciones, SNI, ALPN y revocación.
  2. Firma tus binarios (Authenticode) para evitar avisos de SmartScreen al redistribuir DLLs.
  3. Usa SafeHandle en P/Invoke para garantizar liberación determinista de recursos.
  4. Expón métricas (Δhandshake, re‑usos de sesión, curva elíptica negociada) para detectar regresiones.
  5. Delega la validación de certificados al mismo motor en todas las plataformas (por ejemplo, X509Chain) o documenta claramente la diferencia.

Preguntas frecuentes

¿Puedo usar OpenSSL sólo para determinados sockets?

Sí. Tu implementación puede ofrecer clases paralelas (MyOpenSslStream) y utilizarlas sólo cuando sea imprescindible, manteniendo SslStream para el resto.

¿Afecta esto a HttpClient?

HttpClient usa SocketsHttpHandler, que encapsula SslStream. Por tanto, si quieres OpenSSL tendrás que inyectar tu propio HttpMessageHandler que use tu wrapper TLS.

¿Qué pasará con .NET 9 o 10?

De momento no hay hojas de ruta públicas que contemplen un backend OpenSSL en Windows. La prioridad está en QUIC y HTTP/3, los cuales siguen apoyándose en Schannel a través de MsQuic.

Conclusión práctica

Si tu proyecto necesita funciones que Schannel no ofrece (o las necesitas ya, sin esperar a próximas versiones de Windows), la única vía realista es integrar OpenSSL por tu cuenta o a través de una biblioteca especializada. La inversión no es trivial: tendrás que compilar, firmar, mantener y auditar ese nuevo componente para siempre. Pero a cambio obtendrás control absoluto sobre la capa TLS, la posibilidad de adoptar estándares emergentes con rapidez y un comportamiento idéntico en todas las plataformas.

En resumen: SslStream no puede forzarse a usar OpenSSL en Windows. Si tu caso de uso lo exige, crea tu propio stream o adopta una librería que ya lo encapsule, y prepárate para gestionar la complejidad operativa y los riesgos asociados.

C#
Windows TLS OpenSSL .NET SslStream
Índice