使用mitmsqlproxy连接AzureSQL遇SSL版本号错误求助

针对你遇到的mitmsqlproxy连接微软原生AzureSQL时触发的SSL routines: wrong version number错误，结合你已做的尝试，给你几个实际可行的排查和修复方向：

1. 强制限定SSL/TLS版本范围 #

微软原生AzureSQL仅支持TLS 1.2及以上版本，而代理默认的SSL上下文可能包含了旧版本协议（比如SSLv3、TLS 1.0/1.1），导致握手时版本协商失败。可以修改代码中创建SSL上下文的逻辑，强制禁用旧协议：

from OpenSSL import SSL
# 替换原有的上下文创建代码
ctx = SSL.Context(SSL.TLS_METHOD)
# 禁用所有旧版SSL/TLS协议
ctx.set_options(SSL.OP_NO_SSLv2 | SSL.OP_NO_SSLv3 | SSL.OP_NO_TLSv1 | SSL.OP_NO_TLSv1_1)

2. 检查SNI（服务器名称指示）配置 #

微软原生AzureSQL对SSL握手的SNI要求更严格，代理连接后端时如果未携带正确的SNI，服务器可能返回误导性的版本错误。在建立后端SSL连接时添加SNI设置：

# 在创建SSL连接后、握手前添加
ssl_conn.set_tlsext_host_name("<你的AzureSQL服务器域名>".encode('utf-8'))

3. 排查预登录包的转发逻辑 #

对比AWS托管AzureSQL和原生AzureSQL的初始连接抓包，预登录包（Pre-Login）的格式或内容可能存在差异。原代理代码可能对某些数据包做了截断/修改（比如你修改的data[8:]逻辑），需要确保所有初始数据包完整转发，不要做任何未经验证的裁剪。

重点检查do_handshake()附近的代码，确认在触发SSL握手前，客户端和服务器的预登录交互已经完整完成，没有提前启动SSL握手。

4. 验证后端连接的SSL触发时机 #

微软原生AzureSQL可能在连接初期就要求SSL握手，而原代理的逻辑可能是在收到特定数据包后才启动SSL。可以尝试调整代理的SSL启动时机：

• 取消原有的握手触发条件，在建立后端连接后立即启动SSL握手
• 或者根据预登录包中的Encryption字段动态判断是否需要启动SSL，而非固定触发

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