“TLS 错误启动”的要点是，在正常的 TLS 握手结束时，每一方都向对等方发送一条消息，并且在发送应用程序数据之前Finished应该等待来自该对等方的消息。Finished“错误开始”删除了“应该等待”。然后每一方都可以立即发送应用程序数据。Finished如果发送第一个的一方也是首先发送应用数据的一方，这意味着较低的延迟。

请注意，有两种 TLS 握手，“完整”和“缩写”握手。后者用于“恢复” TLS 会话，即在已交换的主密钥上重新计算新的会话密钥；缩写的握手仅使用对称加密，并且需要较少的网络交换。值得注意的一点是，在完全握手中，客户端Finished首先发送它的消息，而在一个简短的握手中，服务器Finished首先发送它的消息。

在 HTTPS 和 Web 站点的上下文中，客户端（Web 浏览器）通常会启动一次完整的 TLS 握手。然后客户端也可以打开其他一些并行连接，这一次使用缩写握手。每个连接将用于发送多个 HTTP 请求。如果连接超时，浏览器将再次使用简短的握手打开一个新连接。由于 HTTPS 是 HTTP-within-TLS 并且 HTTP从客户端的请求开始，因此“错误启动”优化仅对与服务器的第一个 TLS 连接中的第一个 HTTP 请求产生任何改进。这不是真正的免费午餐，最多是免费的开胃菜。

从密码学上讲，错误启动的情况是客户端在确认它确实与真正的服务器通信之前接受发送其数据（HTTP 请求）：此时，从客户端的角度来看，服务器已被隐式验证. 应用数据使用从密钥交换派生的会话密钥加密，该密钥交换使用经过身份验证的服务器公钥（来自服务器证书的密钥），因此冒充攻击者可以通过这种方式获取信息没有真正的风险，至少只要密钥交换算法和对称加密算法是安全的。但是，客户端在发送请求时没有任何证据表明目标服务器确实知道连接尝试。这在 HTTPS 的上下文中是无害的. 大胆假设它一般没有害处。