当建立 TLS / LDAP 或 TLS / HTTP 连接时，线路上会发生什么？
我正在重新表述我的问题，希望能得到更好的答复。我在 serverfault 这里提出了类似的问题，并且认为正确且有效的 TLS 服务器是需要“STARTTLS”命令的服务器。
是否可以将 STARTTLS 发送到正确配置的 LDAP 或 HTTP TLS 服务器而不需要额外的端口？我知道从 SMTP 的角度来看这是正确的，但不确定我可以在多大程度上将这些经验应用到其他协议中。
我花了时间阅读（但没有完全掌握）
- TLS 规范
- 之间的差异 < a href="http://novosial.org/openssl/tls-name/" rel="nofollow noreferrer">TLS 和 SSL
- SSL 规范
问： 在 LDAP 或 HTTP 会话上的 TLS 之前，线路上会发生什么设置？由于这是基于 TCP 的，我可以简单地远程登录到该端口并发出一些命令来验证它是否正常工作（到目前为止）？
I'm rewording my question so hopefully I can get a better response. I asked a similar question on serverfault here, and think that a proper and valid TLS server is one that expects the "STARTTLS" command.
Is it true that STARTTLS can be issued to a properly configured LDAP or HTTP TLS server without needing an extra port? I know that this is true from an SMTP perspective, but aren't sure how broadly I can apply those experiences to other protocols.
I've spent time reading (but not fully grasping)
- The TLS Spec
- Differences between TLS and SSL
- The SSL Spec
Q: What happens on the wire right before the TLS over LDAP or HTTP session is set up? Since this is TCP based can I simply telnet to that port and issue some command to verify it's working (up to that point)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“STARTTLS 命令”是在 TLS 规范之外定义的内容。这是客户端通过先前未加密的连接向服务器发送的内容，表示“好吧，让我们现在开始 TLS 协商”。
并非所有协议都实现这样的命令。 SMTP 可以，但 HTTP 和 LDAP（据我所知）不可以。
当不存在启动 TLS 的显式命令时，通常的替代方法是指定特定端口：例如用于 HTTP 的 443 和用于 LDAP 的 636。在这种情况下，一旦 TCP 连接建立，TLS 协商就会开始。
openssl 中的“s_client”工具是一个很好的故障排除工具。例如：
将连接并转储服务器的证书。将其视为 TLS 连接的“Telnet”。 （当然，LDAP 不是基于文本的协议，因此一旦建立 TLS 连接，您就无法通过键盘执行任何有用的操作。）
The "STARTTLS command" is something that's defined outside the TLS spec. It's what a client sends to a server on a previously unencrypted connection to say "Ok, lets start a TLS negotiation now".
Not all protocols implement such a command. SMTP does, but HTTP and LDAP (as far as I'm aware) do not.
When an explicit command to begin TLS is not present, the usual alternative is to designate a specific port: like 443 for HTTP(s) and 636 for LDAP(s). In that case, the TLS negotiation begins as soon as the TCP connection is established.
A good tool for troubleshooting that is the "s_client" tool in openssl. For example:
will connect and dump out the server's certificate. Think of it as being like "Telnet" for a TLS connection. (Of course, LDAP is not a text-based protocol, so you can't do anything useful from the keyboard once the TLS connection is established.)
LDAP 使用扩展操作来启动 TLS 层的安装。另请参阅 RFC 中的第 4.14 节。
LDAP uses an extended operation to initiate installation of the TLS layer. See also section 4.14 in the RFC.
SSL 和 TLS 在使用方式上几乎没有什么区别。然而，预先建立 SSL/TLS 和使用诸如
STARTTLS之类的命令之间存在根本区别。有时，“TLS”与“SSL”相对，表示“使用 STARTTLS 模式”，但这是不正确的。预先 TLS/SSL
在这种情况下，客户端会先于其他操作启动 TLS/SSL 连接，因此首先发生 SSL/TLS 握手。一旦安全套接字启动，使用它的应用程序就可以开始发送 TLS 之上协议的各种命令（例如 HTTP、此模式下的 LDAP、SMTP）。
在此模式下，SSL/TLS 版本必须在与其普通版本不同的端口上运行，例如：HTTPS 在端口 443 上运行、LDAPS 在端口 636 上运行、IMAPS 在端口 993 上运行，而不是分别在端口 80、389、143 上运行。
实现这些应用程序协议的层几乎不需要知道它们是在 TLS/SSL 之上运行的。有时，它们只是通过sslwrap等工具进行隧道传输。
STARTTLS 之后的 TLS（或等效项）
TLS 规范允许握手随时发生，包括在通过同一 TCP 连接以普通 TCP 交换一些数据之后。
一些协议（包括 LDAP）包含一个命令来告诉应用程序协议将进行升级。本质上，LDAP 通信的第一部分以纯文本形式进行，然后发送
STARTTLS消息（仍然以纯文本形式），这表明当前的 TCP 连接将被重用，但接下来的命令将封装在 TLS/SSL 层中。在此阶段，发生 TLS/SSL 握手，并且通信“升级”为 TLS/SSL。只有在此之后，通信才通过 TLS/SSL 得到保护，并且客户端和服务器都知道它们必须从 TLS 层包装/解开其命令（通常在 TCP 层和应用程序层之间添加 TLS 库）。每个协议中
STARTTLS如何实现的详细信息因协议而异（因为这必须在某种程度上与使用它的协议兼容）。即使 HTTP 也有一个使用此机制的变体，尽管它几乎从不支持： RFC 2817 Upgrading to TLS Within HTTP /1.1。这与 HTTPS 的工作方式 (RFC 2818) 完全不同，HTTPS 启动 TLS/首先是 SSL。
STARTTLS方法的优点是您可以在同一端口上运行安全变体和普通变体，缺点是由此产生的后果，特别是潜在的降级攻击或可能的配置错误。（编辑：正如 @GregS 指出的那样，我删除了一个不正确的句子，谢谢。）
（编辑：我还在 < a href="https://serverfault.com/questions/178561/what-are-the-exact-protocol-level-differences- Between-ssl-and-tls/179139#179139">ServerFault 上的这个答案.)
There are very few differences between SSL and TLS in the way they are used. There is, however, a fundamental difference between up-front establishment of SSL/TLS and the use of a command such as
STARTTLS. Sometimes, "TLS" is used in contrast to "SSL", to mean "using a STARTTLS mode" but this is incorrect.Up-front TLS/SSL
In this case, the client initiates the TLS/SSL connection before anything else, so SSL/TLS handshake happens first. Once the secure socket is up, the application using it can start sending the various commands for the protocol above TLS (e.g. HTTP, LDAP in this mode, SMTP).
In this mode, the SSL/TLS versions have to run on a different port from their plain counterparts, for example: HTTPS on port 443, LDAPS on port 636, IMAPS on port 993, instead of 80, 389, 143 respectively.
The layers implementing these application protocols barely need to know they're running on top of TLS/SSL. Sometimes, they're simply tunneled in tools such as sslwrap.
TLS after STARTTLS (or equivalent)
The TLS specification allows for the handshake to happen at any time, including after having exchanged some data in plain TCP over the same TCP connection.
Some protocols, including LDAP, incorporate a command to tell the application protocol there will be an upgrade. Essentially, the first part of the LDAP communication happens in plain text, then a
STARTTLSmessage is sent (still in plain text), which indicates that the current TCP connection will be reused but that the next commands will be wrapped within a TLS/SSL layer. At this stage, the TLS/SSL handshake happens and the communication is "upgraded" to TLS/SSL. Only after this the communication is secured via TLS/SSL, and both the client and servers know that they have to wrap/unwrap their commands from the TLS layer (typically adding a TLS library between the TCP layer and the application layer).The details of how
STARTTLSis implemented within each protocol vary depending on the protocol (because this has to be compatible with the protocol using it to some extent).Even HTTP has a variant using this mechanism, although it's mostly never supported: RFC 2817 Upgrading to TLS Within HTTP/1.1. This is completely different from the way HTTPS works (RFC 2818), which initiates TLS/SSL first.
The advantages of the
STARTTLSapproach is that you can run both secured and plain variants on the same port, the disadvantages are the consequences of that, in particular potential downgrade attacks or possible mistakes in the configuration.(EDIT: I've removed an incorrect sentence, as @GregS pointed out, thanks.)
(EDIT: I've also put more on SSL vs. TLS in this answer on ServerFault.)