Telnet 在端口 (443) 上被阻止，但仍允许同一主机和端口上的 Web 服务请求

Posted 2023-03-16

【中文标题】Telnet 在端口 (443) 上被阻止，但仍允许同一主机和端口上的 Web 服务请求

【英文标题】：Telnet is blocked on a port (443) while still allowing web service request on the same host and port

【发布时间】：2014-10-14 10:58:09

【问题描述】：

我一直在尝试连接到合作伙伴的 Web 服务，该服务在 HTTPS 默认端口 443 上运行。我一直错误地认为他们没有为我们打开防火墙端口，因为我的服务器上的 telnet 无法建立连接。例如，我正在输入：

$ telnet <vendor's host> 443 

等待很长时间（大约 15-20 秒）后，它会打印出它已连接但立即也说连接已关闭：

Connected to <host>.
Escape character is '^]'.
Connection to <host> closed by foreign host.

但是，在从服务器运行 SOAP UI 并点击托管在同一主机和端口上的 URL 时工作正常。

只是想知道为什么 telnet 连接会跳闸。服务器端是否有任何可能的设置？

【参考方案1】：

也许您实际上正在建立 Telnet 连接？但随后它关闭，因为服务器没有发现有趣的对话，因为服务器正在等待 SSL 协商完成。

了解 Telnet 与 TCP 没有太大区别（][CyberPillar: Telnet 可能会讨论这一点 - 完全公开，我拥有 Cyber​​Pillar） 那么您希望 SSL 服务器如何处理 TCP 连接？对于 HTTPS 服务器（这是我的假设，因为您提到了 TCP 端口 443），我希望 HTTPS 服务器希望立即执行 SSL 协商。如果客户端没有成功提供 SSL 协商，那么客户端可能只是试图耗尽服务器资源的攻击者。因此，服务器不会通过以有趣的方式响应（例如打印出信息性消息）来浪费资源。在大多数情况下，这将是提供最理想结果的行为。来自知道自己在做什么的客户端的大多数连接将是来自知道如何协商 SSL 的客户端的 HTTPS 连接。

我希望许多其他旨在使用加密的协议也能得到类似的结果。顺便说一句，我不知道任何特定的技术规范/要求都绝对需要这种行为。但是，我所知道的是，您提供的描述（记录了您所经历的行为）对我来说真的一点也不奇怪。也许只是从我的一些经验来看，这是我所期望的。你描述的结果对我来说并不奇怪，即使你的防火墙什么也没做。因此，我不知道您的防火墙是否有效地对该流量进行了任何值得注意的事情。可能是防火墙阻止了它，或者防火墙将它传递给了一个 HTTPS 服务器，它只是以一种你没有预料到的方式处理连接。

【讨论】：

原始问题中显示的输出确实显示Connected to <host>，因此套接字确实连接了。我认为您几乎可以肯定 SSL 协商失败并关闭连接是正确的。