基于Bouncy Castle的PskTlsClient连接OpenSSL测试服务遇IO异常求助

从你的描述来看，问题出在TLS握手阶段的协议版本和密码套件不匹配——你的Bouncy Castle客户端没有明确指定服务端要求的TLS版本和密码套件，导致握手协商失败，最终触发超时错误。

核心原因 #

你的OpenSSL服务端只启用了ECDHE-PSK-CHACHA20-POLY1305这个密码套件，并且你用s_client测试时明确指定了-tls1_2。但默认的PskTlsClient类：

1. 可能支持的协议版本范围过宽（比如包含TLS 1.0/1.1，而服务端仅接受TLS 1.2）
2. 默认的密码套件列表里没有包含ECDHE-PSK-CHACHA20-POLY1305，导致服务端找不到匹配的套件，直接终止握手。

修复代码 #

你需要自定义一个PskTlsClient的子类，明确指定TLS 1.2协议和对应的密码套件：

using Org.BouncyCastle.Crypto.Tls;

class CustomPskTlsClient : PskTlsClient
{
    public CustomPskTlsClient(TlsCipherFactory cipherFactory, TlsPskIdentity pskIdentity) 
        : base(cipherFactory, pskIdentity)
    {
    }

    // 强制使用TLS 1.2，和测试用的s_client保持一致
    public override ProtocolVersion[] GetProtocolVersions()
    {
        return new[] { ProtocolVersion.TLSv12 };
    }

    // 只包含服务端要求的密码套件
    public override int[] GetCipherSuites()
    {
        return new[] { CipherSuite.TLS_ECDHE_PSK_CHACHA20_POLY1305 };
    }
}

然后在Main方法里替换原来的客户端实例：

// 替换原来的var client = new PskTlsClient(...)
var client = new CustomPskTlsClient(null, pskIdentity);

额外验证点 #

1. PSK与Identity正确性：你的代码里PSK是0x61,0x61,0x61,0x61,0x61（对应hex字符串6161616161），Identity是admin，和服务端参数完全匹配，这部分是没问题的。
2. SNI设置：如果你的服务端后续需要绑定域名，可能需要添加SNI支持，但当前测试场景下不需要。

为什么openssl s_client能正常工作？ #

因为你给s_client明确指定了-tls1_2和匹配的PSK/Identity，它会向服务端发送精确的协议版本和套件协商请求，而你的Bouncy Castle客户端默认没有做这些限制，导致协商失败。

内容的提问来源于stack exchange，提问作者lunatic84