我的TLS1.3之旅

【001】The connection itself is secure because symmetric cryptography is used to encrypt the data transmitted.
【002】The keys are uniquely generated for each connection and are based on a shared secret negotiated at the beginning of the session, also known as a TLS handshake.
【003】Many IP-based protocols, such as HTTPS, SMTP, POP3, FTP support TLS to encrypt data.
【004】(RFC 8446).
【005】(0-RTT)。
【006】 SSL Server Test tool：https://www.ssllabs.com/ssltest/
google示例：

【007】TLS is a so-called “hybrid” cryptosystem。Hybrid schemes are the predominant form of encryption used on the Internet and are used in SSH, IPsec, Signal, WireGuard and other protocols. In hybrid cryptosystems, public key cryptography is used to establish a shared secret between both parties, and the shared secret is used to create symmetric keys that can be used to encrypt the data exchanged.public keys are used to establish symmetric keys.
【007-1】RSA key exchange：one party encrypts the shared secret with the other party’s public key and sends it along. The other party then uses its private key to decrypt the shared secret and … voila! They both share the same secret.
【007-1-1】In TLS’s RSA key exchange, the shared secret is decided by the client, who then encrypts it to the server’s public key (extracted from the certificate) and sends it to the server.
【007-2】Diffie-Hellman key agreement：the client and server both start by creating a public-private key pair. They then send the public portion of their key share to the other party. When each party receives the public key share of the other, they combine it with their own private key and end up with the same value: the pre-main secret.
【007-2-2】The server then uses a digital signature to ensure the exchange hasn’t been tampered with. This key exchange is called “ephemeral” if the client and server both choose a new key pair for every exchange.
【007-3】To reduce the risks caused by non-forward secret connections and million-message attacks, RSA encryption was removed from TLS 1.3, leaving ephemeral Diffie-Hellman as the only key exchange mechanism.
【008】When it comes to cryptography, giving too many options leads to the wrong option being chosen.
【009】TLS 1.3 takes the opinionated route, restricting the Diffie-Hellman parameters to ones that are known to be secure.
【010】Symmetric ciphers usually come in two main forms: block ciphers and stream ciphers.
【010-1】To encrypt with a stream cipher, you take your message and combine it with the key stream by XORing each bit of the key stream with the corresponding bit of your message.o decrypt, you take the encrypted message and XOR it with the key stream。Examples of pure stream ciphers are RC4 and ChaCha20。
【011】The only type of symmetric crypto allowed in TLS 1.3 is a new construction called AEAD (authenticated encryption with additional data), which combines encryption and integrity into one seamless operation.
【012】认证

【013】TLS 1.3 removes many of these legacy features, allowing for a clean split between three orthogonal negotiations：
Cipher + HKDF Hash
Key Exchange
Signature Algorithm

【014】1-RTT mode：
TLS 1.3 now has a radically simpler cipher negotiation model and a reduced set of key agreement options (no RSA, no user-defined DH parameters). This means that every connection will use a DH-based key agreement and the parameters supported by the server are likely easy to guess (ECDHE with X25519 or P-256). Because of this limited set of choices, the client can simply choose to send DH key shares in the first message instead of waiting until the server has confirmed which key shares it is willing to support. That way, the server can learn the shared secret and send encrypted data one round trip earlier. Chrome’s implementation of TLS 1.3, for example, sends an X25519 keyshare in the first message to the server.
【014-1】

【014-2】In the rare situation that the server does not support one of the key shares sent by the client, the server can send a new message, the HelloRetryRequest, to let the client know which groups it supports. Because the list has been trimmed down so much, this is not expected to be a common occurrence.
【015】0-RTT resumption：
It lets clients send encrypted data in their first message to the server, resulting in no additional latency cost compared to unencrypted HTTP。
【015-1】In TLS 1.2, there are two ways to resume a connection, session ids and session tickets. In TLS 1.3 these are combined to form a new mode called PSK (pre-shared key) resumption. The idea is that after a session is established, the client and server can derive a shared secret called the “resumption main secret”. This can either be stored on the server with an id (session id style) or encrypted by a key known only to the server (session ticket style). This session ticket is sent to the client and redeemed when resuming a connection.
【015-2】For resumed connections, both parties share a resumption main secret so key exchange is not necessary except for providing forward secrecy. The next time the client connects to the server, it can take the secret from the previous session and use it to encrypt application data to send to the server, along with the session ticket. Something as amazing as sending encrypted data on the first flight does come with its downfalls.
【015-3】
【015-4】An example of dangerous replayed data is anything that changes state on the server. If you increment a counter, perform a database transaction, or do anything that has a permanent effect, it’s risky to put it in 0-RTT data.
As a client, you can try to protect against this by only putting “safe” requests into the 0-RTT data. In this context, “safe” means that the request won’t change server state. In HTTP, different methods are supposed to have different semantics. HTTP GET requests are supposed to be safe, so a browser can usually protect HTTPS servers against replay attacks by only sending GET requests in 0-RTT. Since most page loads start with a GET of “/” this results in faster page load time.
【015-5】To help prevent against this failure case, TLS 1.3 also includes the time elapsed value in the session ticket. If this diverges too much, the client is either approaching the speed of light, or the value has been replayed. In either case, it’s prudent for the server to reject the 0-RTT data.
【016】Deployability
it has to be backwards compatible with existing software.
【017】TLS位置：

【018】TLS 1.3握手框架：

第1步，客户端发送 ClientHello 消息，该消息主要包括客户端支持的协议版本、DH 密钥交换参数列表 KeyShare；

第2步，服务端回复 ServerHello，包含选定的加密套件；发送证书给客户端；使用证书对应的私钥对握手消息签名，将结果发送给客户端；选用客户端提供的参数生成 ECDH 临时公钥，结合选定的 DH 参数计算出用于加密 HTTP 消息的共享密钥；服务端生成的临时公钥通过 KeyShare 消息发送给客户端；

第3步，客户端接收到 KeyShare 消息后，使用证书公钥进行签名验证，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥；

第4步，双方使用生成的共享密钥对消息加密传输，保证消息安全。
【019】TLS1.3的握手流程于TLS1.2最大的区别，就在于TLS1.3提前走了加密，TLS1.2需要在双方明文交换了key exchange信息之后才会走加密通道，而TLS1.3在sever端发送玩ServerHello信息之后就会走加密通道，就连证书信息也是加了密的。
【020】TLS1.2比TLS1.3在握手过程中多了一次握手，握手是为了协商出一个client和server端都认可的一个对称秘钥。
ECDH的秘钥协商过程：给定一个大家都知道的大数G，client在每次需要和server协商秘钥时，生成一段随机数a，然后发送A=aG给server，server收到这段消息（aG）后，生成一段随机数b，然后发送B=bG给client，然后server端计算(aG)b作为对称秘钥，client端收到后bG后计算a*(Gb)，因为(aG)b = a(Gb)，所以对称秘钥就是aGb。
在TLS1.2中，client发送client_hello，server收到后发送**server_hello和ECC证书（B =bG），client收到后就生成随机数a，然后发送aG给server**,并记录秘钥，server收到aG后计算对称秘钥，握手就结束了。
TLS1.3中的key_share，这段的功能就是直接记录了a*G，然后包含在client_hello中。然后server收到后在server_hello的key_share段中记录b*G。所以TLS1.3一个RTT就搞定握手了。
证书的作用，证书含有服务端公钥，服务端用证书对应的私钥对握手消息签名，客户端收到这个证书后验证服务器的证书中的公钥的合法性，用这个公钥去验签。另一对密钥对则用于ECDH密钥协商，产生对称加密密钥aGb
【021】为什么需要公钥证书？
数字签名可以识别篡改或者发送者身份是否被伪装，也就是验证消息的完整性，还可以对消息进行认证。还可以防止抵赖。数字签名需要用公钥来确认发送者的身份，用对方的公钥进行验签。
为了验证得到的公钥是否合法，必须使用公钥证书。证书是将公钥当做一条消息，由一个可信的第三方对其签名后所得到的。

第一步中，Bob 的密钥可以是自己生成的，也可以由认证机构代为生成。
第三步中，认证机构在拿到 Bob 的公钥以后会开始认证这个公钥是否是 Bob 的。有三种验证等级，Class 1 通过邮箱中的邮件进行确认本人身份；Class 2 通过第三方数据库来确认本人身份；Class 3 通过当面认证和身份来确认本人身份。等级越高，身份认证越严格。
第五步中，Alice 使用认证机构 Trent 的公钥对证书中的数字签名进行验证，如果验证成功，就确认了证书中所包含的公钥是 Bob 的。
第六步中，图上虽然标识的是“公钥加密”的方式，但实际上这一步用混合加密的方式也是可以的。
【021-1】PKI
类似 Bob 注册公钥的用户：

生成密钥对(可以自己生成也可以由认证机构生成)
在认证机构注册公钥
向认证机构申请证书
申请作废已注册的证书
解密收到的密文
对消息进行数字签名
类似 Alice 使用公钥的用户

将消息加密后发送给接收者
验证数字签名
认证机构(Certification Authority，CA)是对证书进行管理的人。主要负责以下操作：

生成密钥对(也可以由用户生成)
对注册公钥的人进行身份认证
生成并颁发证书
作废证书
认证机构中还可以细分一个注册机构(Registration Authority，RA)，注册机构专门处理注册相关的业务，认证机构专门颁发证书和作废证书。
仓库(repository)是一个保存证书的数据库。仓库也叫证书目录。作废的证书也需要制作一张证书作废清单(Certificate Revocation List，CRL)。
【021-2】证书链

【022】认证、机密性、完整性

我的TLS1.3之旅相关推荐

微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅
本文由微信开发团队工程是由"oneliang"原创发表于WeMobileDev公众号,内容稍有改动. 1.引言 Kotlin 是一个用于现代多平台应用的静态编程语言,由 JetBr ...
hadoop学习之旅1
大数据介绍大数据本质也是数据,但是又有了新的特征,包括数据来源广.数据格式多样化(结构化数据.非结构化数据.Excel文件.文本文件等).数据量大(最少也是TB级别的.甚至可能是PB级别).数据增长 ...
基于设计模式的学习之旅-----访问者模式(附源码)
基于设计模式的学习之旅-----访问者模式 1.初始访问者模式 2.什么是访问者模式表示一个作用于某对象结构中的各元素的操作.它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作. 3.模 ...
使用CEfSharp之旅（7）CEFSharp 拦截 http 请求 websocket 内容
使用CEfSharp之旅(7)CEFSharp 拦截 http 请求 websocket 内容原文:使用CEfSharp之旅(7)CEFSharp 拦截 http 请求 websocket 内容版 ...
VC开发Windows客户端软件之旅——前言
从第一次拖着行李入京找活,至今已工作若干年了.这些年一直追逐自己的梦想,跑过三个城市,换了三份工作,认识了很多业内的朋友.和朋友们闲聊时,发现很多人都已经不再做客户端软件了.有的转去做管理,有的转去做 ...
unity 200.8m yoy_专场分享会|大会最新Unity、中创文旅专场预告来啦！
北京国际游戏创新大会将于9月25日-27日分别在中华世纪坛发布厅.中华世纪坛剧场.京都信苑国际厅.京都信苑欧式厅.京都信苑圣马可厅.京都信苑第三会议室,6大场馆举办129场游戏行业主题分享,之前小编已 ...
自定义html托管,10分钟搞定“傻瓜式”的静态网站搭建托管之旅
原文发布于微信公众号:腾讯云存储(关注有惊喜) 静态网站:有别于动态网站,它就是只包含静态内容(如图片.音频.视频.HTML.CSS.JS)的网站,不依赖服务器端动态渲染页面. 那么静态网站托管应该如 ...
C#发现之旅第一讲 C#－XML开发
C#发现之旅第一讲 C#-XML开发袁永福 2008-5-15 系列课程说明为了让大家更深入的了解和使用C#,我们将开始这一系列的主题为"C#发现之旅"的技术讲座.考虑 ...
puppeteer爬虫的奇妙之旅
@(爬虫)[puppeteer|] 爬虫又称网络机器人.每天或许你都会使用搜索引擎,爬虫便是搜索引擎重要的组成部分,爬取内容做索引.现如今大数据,数据分析很火,那数据哪里来呢,可以通过网络爬虫爬取啊. ...
F#探险之旅（三）：命令式编程（上）
F#系列随笔索引页面在本系列的第二部分(函数式编程上.中.下)中,我们了解了如何使用F#进行纯粹的函数式编程.但是在一些情况下,比如I/O,几乎不能避免改变状态,也就是说会带来side effect ...

我的TLS1.3之旅

我的TLS1.3之旅相关推荐

最新文章

热门文章