tls1.0 tls1.2_tls结束的开始1 0 1 1 1 2

tls1.0 tls1.2

So after nearly five years in the making and 28 drafts, the IETF (Internet Engineering Task Force) rolled out the TLS (Transport Layer Security) 1.3 standard an it is now pushing its way to the front of the queue [here]:

因此，经过近五年的编写和28项草案，IETF(Internet工程任务组)推出了TLS(传输层安全性)1.3标准，现在它正在将其推向队列的前端[ 此处 ]：

演示地址

The rapid growth has been pushed by browser updates. Overall it fixes many of the recently discovered problems and improves performance (and also dumps legacy methods). A new feature — Zero-RTT (zero round trip time resumption) — has been introduced to speed up things, but could actually be opening up a whole lot of new vulnerabilities.

浏览器更新推动了快速增长。 总体而言，它解决了许多最近发现的问题，并提高了性能(并转储了旧方法)。 引入了一项新功能-Zero-RTT(零往返时间恢复)以加快处理速度，但实际上可能会打开许多​​新漏洞。

前向保密 (Forward secrecy)

An important update is where static RSA and Diffie-Hellman ciphers have been removed, and where all of the public key methods are now forward secrecy (FS). With this a comprise of the long-term keys will not compromise any previous session keys. For example if we send the public key of the server to the client, and then the client sends back a session key for the connection which is encrypted with the public key of the server, then the server will then decrypt this and determine the session. A leakage of the public key of the server would cause all the sessions which used this specific public key to be compromised. FS thus aims to overcome this by making sure that all the sessions keys could not be compromised, even though the long-term key was compromised. The problem with using the RSA method to pass keys is that a breach of the long keys would breach the keys previously used for secure communications.

一个重要的更新是，已删除静态RSA和Diffie-Hellman密码，并且所有公钥方法现在都为正向保密 (FS)。 这样，长期密钥的组成将不会损害任何先前的会话密钥。 例如，如果我们将服务器的公共密钥发送给客户端，然后客户端将使用服务器的公共密钥加密的连接的会话密钥发回，则服务器将对其解密并确定会话。 服务器公钥的泄漏将导致使用该特定公钥的所有会话受到损害。 因此，FS旨在通过确保不会破坏所有会话密钥来解决此问题，即使长期密钥已被破坏。 使用RSA方法传递密钥的问题是长密钥的破坏会破坏以前用于安全通信的密钥。

Another important concept is where is key is ephemeral. With some key exchange methods, the same key will be generated if the same parameters are used on either side. This can cause problems as an intruder could guess the key, or even where the key was static and never changed. With ephemeral methods a different key is used for each connection, and, again, the leakage of any long-term would not cause all the associated session keys to be breached. The problem with the Diffie-Hellman method is that the keys are not ephemeral, so we should avoid it in generating keys.

另一个重要概念是短暂的关键所在。 对于某些密钥交换方法，如果在任一侧使用相同的参数，将生成相同的密钥。 这可能会引起问题，因为入侵者可能会猜出密钥，甚至在密钥是静态的且从未更改过的地方。 使用临时方法，每个连接使用一个不同的密钥，并且，任何长期泄漏都不会导致所有关联的会话密钥被破坏。 Diffie-Hellman方法的问题在于密钥不是临时密钥，因此在生成密钥时应避免使用它。

The answer is to use methods which support FS and which are ephemeral. Within SSL/TLS connections, such as for HTTPS accesses, we can use DHE (ephemeral DH) or Ephemeral Diffie-Hellman with RSA (DHE-RSA) to make sure we do not create the same key. But to support FS, we need a method such as Elliptic Curve Ephemeral Diffie-Hellman with ECDSA (ECDHE-ECDSA) as it supports both ephemeral and FS, and is thus robust against attacks.

答案是使用支持FS且短暂的方法。 在SSL / TLS连接(例如HTTPS访问)中，我们可以使用DHE(临时DH)或带有RSA的临时Diffie-Hellman(DHE-RSA)，以确保我们不创建相同的密钥。 但是要支持FS，我们需要诸如ECDSA的椭圆曲线临时Diffie-Hellman(ECDHE-ECDSA)之类的方法，因为它既支持短暂的，也支持FS，因此对攻击具有强大的抵抗力。

零RTT (Zero-RTT)

There’s a good deal of setting up in an HTTPs connection, such as with a DNS lookup, the 3-way TCP handshake, the TLS handshake, and then the HTTP download of a page. Zero-RTT (Round-Trip Time) aims to cut down this overhead by remembering a previous connection and then restoring it. This latency can be a particular problem on mobile networks (where there is typically no caching of content). With Zero-RTT, HTTPs can have the same latency overhead as HTTP. Unfortunately, it leaves systems open to replay attacks, such as [here]:

在HTTPs连接中进行了大量设置，例如使用DNS查找，3向TCP握手，TLS握手以及页面的HTTP下载。 零RTT(往返时间)旨在通过记住先前的连接然后恢复它来减少开销。 此延迟可能是移动网络(通常不缓存内容)上的一个特殊问题。 使用Zero-RTT，HTTP可以具有与HTTP相同的延迟开销。 不幸的是，它使系统容易受到重放攻击，例如[ here ]：

The IETF final draft does identify the risks around a replay attack with:

IETF最终草案确实确定了围绕以下内容进行重放攻击的风险：

再见了布雷亨巴赫的进攻？ (Goodbye to Bleichenbacher’s Attack?)

This version fixes many of the recent vulnerabilities, including ROBOT. With ROBOT we saw the Bleichenbacher’s attack [here] return, and which exposed many Web sites to attackers.

此版本修复了许多近期的漏洞，包括ROBOT。 随着机器人，我们看到了Bleichenbacher的的攻击[ 这里 ]返回，并暴露出许多网站给攻击者。

演示地址

告别普通的老问好 (Say goodbye to plain old hellos)

The TLS handshake involves a ServerHello being sent back from the server to the client, and which shows the details of the connection:

TLS握手涉及将ServerHello从服务器发送回客户端，并显示连接的详细信息：

演示地址

Within TLS 1.3 this ServerHello is now encrypted, which means that the negotiation of keys and ciphers can now be kept secret.

在TLS 1.3中，此ServerHello现在已加密，这意味着密钥和密码的协商现在可以保密。

关键派生功能 (Key derivation functions)

There are improved key derivation functions within TLS 1.3, and which builds on HMAC-based Extract-and-Expand Key Derivation Function (HKDF) in order to create keys from the given properties. These include a pass phrase and salt, and which creates an encryption key of a given length. You can try HKDF here.

TLS 1.3中改进了密钥派生功能，该功能基于基于HMAC的提取和扩展密钥派生功能(HKDF)来从给定属性创建密钥。 其中包括一个密码短语和一个盐，它们会创建给定长度的加密密钥。 您可以在这里尝试HKDF。

椭圆曲线支持 (Elliptic Curve support)

The world of public key encryption has been moving greatly toward ECC (Elliptic Curve Cryptography), especially with the usage of Curve 25519 (as used in Tor, Bitcoin, and many other applications. TLS 1.3 now directly integrates ECC, as well as improving the methods it uses to generate ECC parameters.

公钥加密的世界已朝着ECC(椭圆曲线密码术)发展，尤其是在使用Curve 25519(Tor，Bitcoin和许多其他应用程序中使用)时。TLS1.3现在直接集成了ECC，并改进了ECC。它用于生成ECC参数的方法。

结论 (Conclusion)

Well. It’s a nip and a tuck, but watch out for 0-RTT, as researchers will be priming their tools to attack it. Overall, do you want speed or security … 0-RTT improves speed, but lowers security. Some are already criticising TLS 1.3 for slow-downs in networks, but this is likely to be caused by poor implementations of the new methods. If you can’t wait for it to be rolled out, the OpenSSL Project has integrated the methods into OpenSSL 1.1.1 (it’s an alpha version, so watch-out!).

好。 这是一个小问题，但是要提防0-RTT，因为研究人员将启动他们的工具来攻击它。 总体而言，您想要速度还是安全性... 0-RTT可以提高速度，但会降低安全性。 一些人已经批评TLS 1.3会降低网络速度，但这很可能是由于新方法实施不当所致。 如果您迫不及待想将其推出，则OpenSSL Project已将这些方法集成到OpenSSL 1.1.1 (这是Alpha版本，请当心！)。

翻译自: https://medium.com/asecuritysite-when-bob-met-alice/the-beginning-of-the-end-for-tls-1-0-1-1-1-2-96635fd090f8

tls1.0 tls1.2