HTTPS es ampliamente utilizado hoy en día, pero como programadores, ¿realmente entendemos esta 'S'? Si aún no lo ha hecho, esta introducción introductoria podría ayudarlo.
Antes de la aparición de TLS (la versión anterior era SSL), para garantizar la seguridad de los datos de la interacción de señalización entre el cliente y el servidor de sus propios productos, muchas empresas personalizaron protocolos de aplicaciones binarias (para aplicaciones) que admitían el cifrado y el descifrado. basado en el protocolo TCP. , o cifrando el cuerpo de la solicitud y respuesta del protocolo HTTP para garantizar la seguridad de los datos.
De cualquier manera, generalmente se cifra mediante un algoritmo de cifrado simétrico. El front-end APP o WEB escribe la clave cuando se empaqueta, el front-end WEB puede obtener la clave directamente al ver el código de cifrado y descifrado JS, y la APP también se puede obtener por descompilación. También hay claves obtenidas solicitando la interfaz de obtención de claves proporcionada por el servidor, pero esta interfaz está en texto sin formato.
Para utilizar el cifrado simétrico, es necesario resolver el problema de la entrega segura de claves de cifrado simétrico para evitar que los piratas informáticos las exploten. Por lo tanto, el cifrado simétrico generalmente se usa para la interacción openapi entre el servidor y el servidor. La parte que proporciona la interfaz proporciona la clave a la otra parte, y la clave generalmente se obtiene mediante acoplamiento manual.
Por ejemplo, el algoritmo de verificación de firma utilizado por el pago de WeChat openapi es un algoritmo de cifrado simétrico para verificar la identidad. Y el token generado por el algoritmo generalmente establece un tiempo de vencimiento corto para evitar el cracking de fuerza bruta, y el token debe regenerarse después del vencimiento.
El cifrado asimétrico consiste en que el contenido cifrado con una clave debe descifrarse con otra clave, es decir, el cifrado con la clave pública, el descifrado con la clave privada, el cifrado con la clave privada y el descifrado con la clave pública.
Si el sitio web adopta el cifrado asimétrico, el servidor genera un par de clave pública y clave privada. Cuando el usuario accede al sitio web, el servidor envía la clave pública a la aplicación o navegador del cliente, y la aplicación o navegador del cliente toma esta clave pública. La clave se utiliza para cifrar los datos de la solicitud, el servidor descifra los datos de la solicitud con la clave privada y cifra los datos de respuesta con la clave privada.
El protocolo TLS admite la autenticación bidireccional y la autenticación unidireccional, pero generalmente solo se utiliza la autenticación unidireccional. La autenticación unidireccional solo requiere que el cliente verifique la autenticidad del servidor, lo que evita que los usuarios accedan a sitios web de phishing. La autenticación bidireccional es que el servidor también verifica la autenticidad del cliente (no discutido en este artículo).
El uso de cifrado asimétrico requiere que el cliente obtenga la clave pública del servidor del sitio web antes de comenzar a transmitir datos cifrados, que es un paso en el proceso de negociación TLS.
Después de usar el cifrado asimétrico, incluso si los datos son secuestrados, dado que el pirata informático no tiene la clave privada, los datos enviados por el cliente al servidor no se pueden descifrar.
Aunque el pirata informático no puede descifrar los datos, porque el pirata informático también puede obtener la clave pública, puede descifrar la respuesta del servidor (escuchas) y puede falsificar al cliente para enviar una solicitud al servidor (edicto falso).
Además, el pirata informático también puede pretender ser el servidor, y el cliente usa la clave pública del pirata informático para completar el protocolo de enlace TLS con el sitio web del pirata informático.
Entonces, ¿cómo resolver el problema de la clave pública que utilizan los piratas informáticos? Es muy simple, ¿no sería bueno mezclar cifrado simétrico y cifrado asimétrico?
Por ejemplo, si el cliente genera aleatoriamente una clave de cifrado simétrica (solo un ejemplo), la cifra con la clave pública del servidor y luego la envía al servidor, esta clave solo puede ser descifrada por la clave privada del servidor. Posteriormente, el cliente y el servidor pueden usar la clave de cifrado simétrica negociada para cifrar los datos y luego transmitirlos. Los piratas informáticos ya no podrán falsificar los datos (transmisión falsa del decreto imperial), ni comprender los datos que interactúan entre el cliente y el servidor (escuchas).
Sin embargo, todavía existe el problema de los piratas informáticos que ingresan al servidor. Por ejemplo, si un pirata informático desarrolla un sitio web de phishing, el nombre de dominio es solo una letra diferente del sitio web de un banco determinado, lo que hace que el usuario piense erróneamente que se trata de un sitio web bancario. Cuando el usuario accede a este nombre de dominio, el cliente y el El sitio web de phishing también puede completar el protocolo de enlace TLS.
Para resolver este problema, existe una organización de CA. El sitio web emite el certificado a través de la agencia de CA (el certificado contiene la clave), el sitio web utiliza la clave privada en el servidor y la clave pública se pasa del sitio web al cliente durante la fase de negociación TLS.
Después de que el cliente obtenga el certificado de clave pública, "pregunte a la agencia de CA" para ver si el certificado de clave pública coincide con el nombre de dominio del sitio web, si es creíble y si está dentro del período de validez.
La agencia CA actúa como una "oficina de seguridad pública".
Entonces, ¿qué es HTTPS? HTTPS es HTTP+TLS, pero no es una simple adición. TLS es el protocolo de seguridad de la capa de transporte, que se encuentra por encima del protocolo TCP.
Al enviar paquetes de datos HTTP, los paquetes de datos HTTP primero se cifran mediante la capa TLS, se convierten en paquetes de datos TLS y finalmente se convierten en paquetes de datos TCP. La capa TLS también descifra primero los datos recibidos en paquetes HTTP. Esto muestra que TLS no tiene nada que ver con el protocolo TCP, y el protocolo de enlace TLS no tiene nada que ver con el protocolo de enlace de tres vías del protocolo TCP.
HTTPS, interacción del protocolo WSS, debe completar el protocolo de enlace TLS antes de enviar la solicitud (HTTP) o el marco de datos (WS) cuando se establece la conexión. Después de que el protocolo de enlace sea exitoso, los datos se pueden enviar y recibir normalmente. Por lo tanto, la verificación de seguridad se basa en la conexión, y también se requiere el protocolo de enlace TLS para volver a conectarse después de la desconexión y la reconexión. Esta es también la razón por la que TLS afecta el rendimiento de la aplicación.
TLS握手的过程中，服务端解密很消耗CPU，TLS握手也增加连接建立的耗时（TCP握手耗时+TLS握手耗时）。
如何降低TLS对性能的影响，常见的方法有：利用CDN走HTTP回源，在CDN侧将TLS卸载掉；或保持长连接，连接尽可能的复用；另外就是TLS的会话恢复。
这里简单介绍下TLS 1.2的握手流程。
从图中可以看出，整个握手流程共10个步骤，两次RTT。下面介绍每个步骤做的事情（对比图中的步骤有合并）。
第1步：客户端与服务端建立TCP连接后，TLS握手从客户端发送Client Hello开始，此消息包含客户端支持的加密套件和一个随机数。
第2步：服务端接收客户端的Client Hello消息后，响应Server Hello消息，此消息携带服务端从客户端提供的支持的密钥套件列表中选择使用的加密套件，同时还会携带一个随机数。
第3步：服务端向客户端发送证书，证书包含公钥和签名。第3步是图中服务端向客户端发送Certificate、Server Key Exchange、Server Hello Done消息的合并，因为这三个消息是合并在一个TLS数据包发送的。
第4步：客户端验证服务端发送的证书，验证通过后，假设选择的加密套件是RSA_WITH_AES_128_CBC_SHA256，那么客户端要生成一个预主密钥（pre-master secret），然后从服务器发送的证书中提取公钥，利用证书的公钥对预主密钥进行RSA加密，再发送给服务端。
此时客户端开始根据发送Client Hello时生成的随机数+服务端Server Hello响应的随机数+客户端生成的预主密钥，生成主密钥，此密钥用于给后续传输的数据进行加解密。
接着，客户端向服务端发送Change Cipher Spec消息，告诉服务端，它后续将切换到使用协商好的加密密钥对数据进行加密再传输。同时也是跟Client Key Exchange（此加密套件需要使用Client Key Exchange消息携带加密后的预主密钥）、Finished消息一起发送，Finished消息使用了该密钥进行加密。
第5步：服务端收到Client Key Exchange消息后，从消息中提取加密过的预主密钥，然后拿证书的私钥解密获取预主密钥。
服务端根据前面客户端发送Client Hello携带的随机数、服务端响应给客户端的随机数，加上这次接收的预主密钥，生成主密钥。
服务端响应Change Cipher Spec消息，告诉客户端，服务器执行相同操作，后续将切换到使用协商好的加密密钥对数据进行加密再传输。同时也是跟Finished消息一起发送，Finished消息使用密钥进行加密。
其中，第1、2、3步是一次往返，第4、5步是一次往返，所以TLS 1.2协议的握手需要两次往返，即2-RTT。
那么，加密套件是什么，用来做什么，以及为什么需要Server Key Exchange消息和Client Key Exchange消息？
加密套件其实就是几类算法的组合，包括签名算法（证书也必须是使用该签名算法的）、数据对称加密算法、协商对称加密密钥的交换算法。
例如加密套件：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA。TLS协议，使用ECDHE做密钥交换算法，RSA为签名算法，AES_128_CBC为数据对称加密算法。
选择何种加密套件，除了根据客户端或服务端优先级外，还会考虑证书使用的签名算法。
例如，当服务器配置RSA签名的证书时，加密套件只能选择签名算法为RSA的加密套件。
如果加密套件选择TLS_ECDHE_RSA_XXX，说明客户端和服务需要使用ECDHE做预主密钥交换算法，不再像RSA_WITH_AES_128_CBC_SHA256那样简单了。
使用ECDHE算法交换预主密钥，握手过程就需要通过Server Key Exchange、Client Key Exchange消息，交换各自本次会话临时生成的密钥对的公钥（不是使用证书的公钥，与证书无关，客户端与服务端都需要各自生成一对公私钥）。用于各自生成对称加密的预主密钥，客户端私钥+服务端公钥，根据椭圆算法算出预主密钥；服务端私钥+客户端公钥，根据椭圆算法算出预主密钥（实际算法实现很复杂）。
两端最终生成的这个预主密钥是相同的，所以最终生成的对称加密密钥肯定也是相同的，否则就不是对称加密了。
可见，TLS证书的公钥和服务器存储的私钥，只用于客户端验证服务端身份。真正用于对数据加密的对称加密密钥，是在握手过程中，根据密钥套件、Server Key Exchange、Client Key Exchange协商出来的。
下图是通过Wireshark抓取的一次TLS 1.2的握手数据包。
前面5个数据包即为TLS 1.2的握手数据包。第一个数据包是Client Hello消息，第二个数据包是Server Hello消息，第三个数据包是服务端响应的Ceritificate、Server Key Exchange、Server Hello Done消息，第四个数据包是客户端发送的Client Key Exchange、Change Cipher Spec和Finshed（Encrypted Handshake Message）消息，第五个数据包是服务端响应的Change Cipher Spec和Finshed（Encrypted Handshake Message）消息。
TLS 1.3握手过程相比以前版本做了不少优化，握手过程耗时降低到1- RTT，客户端发送ClientHello，服务端响应ServerHello之后，握手就完成了，如图所示。（这是通过Wireshark抓包的截图）
ClientHello已经为支持的每种加密套件，生成本该在Client Key Exchange消息传递的参数，不管服务端选择哪种加密套件，后续都节省了一次Client Key Exchange消息，而客户端发送的Change Cipher Spec消息改为在发送应用数据的数据包带上。也不需要Finished消息了。
ServerHello也将Server Key Exchange消息合并在一起发送了。所以总的，就减少了一次RTT。
这里不再展开讨论TLS 1.3的握手细节。想要了解详细的握手过程，以及握手数据包字段的意义，推荐阅读：
- [The TLS 1.3 handshake is a dramatic improvement over the TLS 1.2 handshake] www.thesslstore.com/blog/tls-1-…