TLS 1.3 正式版来了

[blob2015]

互联网工程指导委员会(IETF)释出了传输层安全性协议的最新版本 TLS 1.3。TLS 被广泛用于创建安全连接，TLS 1.3 是基于 TLS 1.2，主要区别是移除了较少使用的弱加密算法，移除 MD5 和 SHA-224 哈希支持，请求数字签名，集成 HKDF，移除许多不安全或过时特性的支持，不再支持静态 RSA 密钥交换，握手将默认使用前向安全 Diffie-Hellman，客户端只需要一次往返就能与服务器建立安全和验证的连接，等等。Firefox 和 Chrome 都已经支持 TLS 1.3 的草拟版本。

https://www.solidot.org/story?sid=57560

OpenSSL 1.1.1 Is Released

Other features in the 1.1.1 release include:

Complete rewrite of the OpenSSL random number generator to introduce the following capabilities
    The default RAND method now utilizes an AES-CTR DRBG according to NIST standard SP 800-90Ar1.
    Support for multiple DRBG instances with seed chaining.
    There is a public and private DRBG instance.
    The DRBG instances are fork-safe.
    Keep all global DRBG instances on the secure heap if it is enabled.
    The public and private DRBG instance are per thread for lock free operation
Support for various new cryptographic algorithms including:
    SHA3
    SHA512/224 and SHA512/256
    EdDSA (including Ed25519 and Ed448)
    X448 (adding to the existing X25519 support in 1.1.0)
    Multi-prime RSA
    SM2
    SM3
    SM4
    SipHash
    ARIA (including TLS support)
Signficant Side-Channel attack security improvements
Maximum Fragment Length TLS extension support
A new STORE module, which implements a uniform and URI based reader of stores that can contain keys, certificates, CRLs and numerous other objects.

https://www.openssl.org/blog/blog/2018/09/11/release111/

[tec1987]

握手时还会泄露SNI的servername吗？ 有没有人抓包测一下，我这目前没有环境。。。

[MeABc]

TLS 1.3 协议是没有了，通过抓包发现一有意思的现象，浏览器貌似不按套路来（可能是兼容性考虑）。简单说就是，服务器是支持 tls 1.3 了，但如果直接用浏览器来爬墙的话，还是会撞墙。爬墙还得要专门的 tls 1.3 客户端才行。所以的大家不要高兴太早。

[MeABc]

呃。。。。facebook 什么的，不要指望浏览器直接打开了。现在是该干什么就干什么去。。。。

[tec1987]

@MeABc 刚看了openssl的文档，不知道是不是因为默认启用了兼容模式 https://wiki.openssl.org/index.php/TLS1.3

Middlebox Compatibility Mode

During development of the TLSv1.3 standard it became apparent that in some cases, even if a client and server both support TLSv1.3, connections could sometimes still fail. This is because middleboxes on the network between the two peers do not understand the new protocol and prevent the connection from taking place. In order to work around this problem the TLSv1.3 specification introduced a “middlebox compatibility” mode. This made a few optional changes to the protocol to make it appear more like TLSv1.2 so that middleboxes would let it through. Largely these changes are superficial in nature but do include sending some small but unneccessary messages. OpenSSL has middlebox compatibility mode on by default, so most users should not need to worry about this. However applications may choose to switch it off by calling the function SSL_CTX_clear_options() and passing SSL_OP_ENABLE_MIDDLEBOX_COMPAT as an argument (see here for further details). If the remote peer is not using middlebox compatibility mode and there are problematic middleboxes on the network path then this could cause spurious connection failures.

这个“中间盒”究竟是个什么鬼？？？

[MeABc]

“中间盒”这个我也不知道啊。。。

不过我抓包显示的结果就如你引用文字的那样：浏览器显示是使用 tls 1.3 了，但背后啥都有，tls1.2，tls1.1。 所以爬墙还是要专门的客户端才行。

[yfdyh000]

看上去是伪装成TLS 1.2结构特征，使一般防火墙、检测设备等放行，不作为未知协议处理。 中间盒就是链路上各路由器、软件/硬件防火墙等。

[SeaHOH]

继续等吧，ESNI 是个单独的标准，并未包含进 TLS1.3。 https://tools.ietf.org/html/rfc8446#section-4.1.2 Structure of TLS1.3 Client Hello message:

  uint16 ProtocolVersion;
  opaque Random[32];

  uint8 CipherSuite[2];    /* Cryptographic suite selector */

  struct {
      ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
      Random random;
      opaque legacy_session_id<0..32>;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^8-1>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

[SeaHOH]

ESNI 以加密扩展 (EncryptedExtensions) 的形式融入 Client Hello，TLS1.2 也可以支持。 实际应用要看服务器商和浏览器商是否支持，不过我觉得很大可能是不会支持 TLS1.2。

[MeABc]

In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value was intended to be associated with the session (Section 3 of [RFC6066]), with the server being required to enforce that the SNI value associated with the session matches the one specified in the resumption handshake. However, in reality the implementations were not consistent on which of two supplied SNI values they would use, leading to the consistency requirement being de facto enforced by the clients. In TLS 1.3, the SNI value is always explicitly specified in the resumption handshake, and there is no need for the server to associate an SNI value with the ticket. Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of Section 4.6.1.

并未包含进 TLS1.3。

大家怎么理解这里。我理解是包含，但是现在要求加密。

[SeaHOH]

extensions: Clients request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 4.2. In TLS 1.3, the use of certain extensions is mandatory, as functionality has moved into extensions to preserve ClientHello compatibility with previous versions of TLS. Servers MUST ignore unrecognized extensions.

The table below indicates the messages where a given extension may appear, using the following notation: CH (ClientHello), SH (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR (CertificateRequest), NST (NewSessionTicket), and HRR (HelloRetryRequest). If an implementation receives an extension which it recognizes and which is not specified for the message in which it appears, it MUST abort the handshake with an "illegal_parameter" alert.

In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each handshake even when in resumption-PSK mode. However, 0-RTT parameters are those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see Section 4.2.10).

我的理解是，标准没有明确要求，但具体实现肯定会使用 ESNI，同时先兼容 SNI，以后再放弃 SNI。

[SeaHOH]

就跟之前 SNI 标准可以添加多个 ServerName，实际实现只能使用一个一样。 标准只是提供了正确的做法，实际使用只要不违反它就行。

[MeABc]

看来我英文有待提高！

[MeABc]

之前我还疑惑，如果直接上新协议，那现在部署的这些 SNIProxy 那还不直接蒙圈。现在算是明白了。

[blob2015]

互联网工程指导委员会(IETF)刚刚发布了正式版的 TLS 1.3，增强了网络加密连接的安全性。IETF 还在制定加密服务器名称指示（Encrypted Server Name Indication），但尚未定稿。如果云服务商普及 TLS 1.3 和 SNI，审查将会变得更困难。因为 SNI 让网络第三方审查者无法知道客户端访问的真实域名，也就无法屏蔽它们认为非法的网站。而 TLS 1.2 下的 SNI 有漏洞，允许审查者区分“真”“假”服务器。TLS 1.3 下的 SNI 修正了这个问题，允许 VPN 服务和 Tor 匿名网络利用 Google、Amazon 或 Microsoft 的服务器绕过审查。

https://www.solidot.org/story?sid=57601

[blob2015]

OpenSSL 1.1.1 Is Released https://www.openssl.org/blog/blog/2018/09/11/release111/

[SeaHOH]

https://blog.cloudflare.com/encrypted-sni/ 终于来了

[blob2015]

@jasonliul @SeaHOH @MeABc @tec1987 @Just2co @yfdyh000 @xyuanmu @Kisesy @破娃酱 @Johnson @phuslu 节日快乐，迟到的祝福 大海兄，那个，俺刚看到，你就发来了 J哥，最近少见你出现啊 ABC兄，作息稍微规律些，身子保重 主任，你这都不冒泡了 妹纸，一切安好，平常心 社长，安好

[tec1987]

https://www.cloudflare.com/ssl/encrypted-sni/ 还是要可靠的DNS解析。。。

[SeaHOH]

Pcap_DNSProxy 很不错，就是不知道之后墙会做出什么针对动作。

[tec1987]

DNS解决方案还是挺多的，DoH、DoT 还有Pcap_DNSProxy 已经集成的DNSCrypt、DNSCurve、DNSSEC等等。。。 这面修改了一个利用压缩指针和EDNS过滤伪包的本地代理 https://github.com/tec1987/Tcp-DNS-proxy/blob/master/tcpdns.py#L180

[eaglexiang]

TLS1.3目前肯定属于普及阶段，会和老版本共存。但很快主流浏览器就会默认使用1.3了

[blob2015]

HTTP-over-QUIC 协议被正式称为 HTTP/3。QUIC 传输协议的开发始于 Google，最初是作为一个 >HTTP-over-UDP 用例，后来演变成了 HTTP/2-encrypted-over-UDP 协议。当 IETF 开始标准化 QUIC 时，它分成了两个层：传输和 HTTP。该传输协议能用于传输其它数据，不限于 HTTP 或类 HTTP 协议，但名字仍然沿用 QUIC。开发者称，Facebook 已经成功完成了在两个 HTTP/3 实现之间的互操作。HTTP 1.1 是在 1999 年发布的，HTTP/2 则是在 2015 年。

https://www.solidot.org/story?sid=58548