https encryption and decryption process

Pre-knowledge

SSL is a Netscape get out of the 90s set of things, in order to solve the problem plaintext HTTP protocol to transmit data. Later SSL slowly became a de facto standard, then put the IETF standardized SSL, called TLS, TLS 1.0 is actually SSL 3.1. So SSL and TLS are often put together written as SSL / TLS, because these two terms in now is actually the same thing. HTTPS is the HTTP protocol using TLS.

And a certificate chain of trust

We know, HTTPS site has its own certificate, indicating their identity. It is to make public transport on the certificate can be trusted nature. The public key is placed inside of a certificate, if the certificate is credible, then the public will also credible. Why a public key can be trusted it? This is to say to the chain of trust and CA. CA refers to the Certificate Authority, CA is the authority, their certificate called the root certificate, which is the operating system trusted root certificate, the certificate is trusted root certificates trusted. Therefore, the certificate issued by the authority can be trusted operating system, which make up the chain of trust.

 

Here at RSA key exchange algorithm as an example, for example, CloudFlare offers Keyless service, the site put on their CDN, do not provide their own private key can be encrypted using SSL link.

 

https encryption and decryption process :

  1. The client initiates https request to the server (the server to a digital certificate, you can make your own, you can also apply to the organization), to ask for the public key to the server.

    General information transmitted band:

    • A random value generated by the client

    • Support SSL / TSL protocol version number

    • Supported encryption algorithms

    • Session ID (to resume the session)

  1. After the server receives the client's request to respond to client and public key (ie certificate) to the client. If with Session ID, restore direct dialogue.

    No Session ID will generally return the information to the client:

    • Select the SSL / TLS protocol version number

    • Select encryption

    • A randomly generated number server

    • The server's certificate

  1. 客户端收到服务端发来的公钥后会解析证书,首先是由TLS层验证服务端证书是否有效,比如说颁发机构、有效时间、证书中的域名与当前会话域名是否匹配等。

    如果发现异常,就会弹出一个警告框,提示证书有问题。

    验证完证书的有效性后,客户端向服务端发送的信息包括有一下内容:

    • 证书校验没有问题的话,生成一个premaster secret(另一个随机值),然后用服务端发过来的证书对该随机值进行加密。

    • 客户端把加密的随机值传回给服务器,加密约定改变,通知服务器,其目的是让服务端得到这个随机值,以后客户端与服务端之间的通信就用协商好的加密方法和密钥进行加密。

    • 客户端握手结束通知。这个报文也是验证消息,是前面发送的所有内容的哈希值,用来供服务器校验。

  2. 服务器用私钥解密后,得到了客户端传过来的随机值(私钥),然后对该值进行对称加密。所谓对称加密就是,将信息和私钥通过某种算法混合在一起,除非知道私钥,否则无法获得内容,因而客户端和服务端都知道这个公钥,只要加密算法够彪悍,私钥够复杂,数据就越安全。

    这是握手过程的最后一步,服务器会把以下信息发送给客户端:

    • 加密约定改变通知,通知客户端,以后的通信都适用协商好的加密方法和密钥进行加密

    • 服务器握手结束通知,该报文也作为校验消息,供客户端验证

  3. 服务端利用这个私钥加密数据并发送数据给客户端,加密的数据可以被还原

  4. 客户端接收到这份数据后,利用私钥解密这段数据,于是获取了加密的内容。即时第三方在数据传输的中途获取了这份数据,没有私钥也束手无策

SSL/TLS层是位于应用层传输层之间,应用层的数据不再直接传递给传输层,而是传递给SSL/TLS层,对传过来的数据进行加密,并增加相应的头信息。

整个对话过程中(握手阶段和其后的对话),服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。

某些客户(比如银行)想要使用外部CDN,加快自家网站的访问速度,但是出于安全考虑,不能把私钥交给CDN服务商。这时,完全可以把私钥留在自家服务器,只用来解密对话密钥,其他步骤都让CDN服务商去完成。

 

加解密相关知识

对称加密

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法,就是加密密钥能够从解密密钥中推算出来,同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中,加密密钥和解密密钥是相同的,所以也称这种加密算法为秘密密钥算法或单密钥算法。

常见的对称加密有:DES(Data Encryption Standard)、AES(Advanced Encryption Standard)、RC4、IDEA

 

非对称加密

与对称加密算法不同,非对称加密算法需要两个密钥公开密钥(public key)和 私有密钥(private key);并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥,非对称加密也称为公钥加密,在密钥对中,其中一个密钥是对外公开的,所有人都可以获取到,称为公钥,其中一个密钥是不公开的称为私钥。

 

主要算法:RSA、Elgamal、背包算法、Rabin、D-H、ECC(椭圆曲线加密算法)

 

使用最广泛的是RSA算法Elgamal是另一种常用的非对称加密算法

 

RSA性能是非常低的,原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期,所以一般的HTTPS连接只在第一次握手时使用非对称加密,通过握手交换对称加密密钥,在之后的通信走对称加密

 

总结:

服务端用RSA生成公钥私钥,把公钥放在证书里发送给客户端,私钥自己保存

客户端接收到公钥后,首先向一个权威的服务器检查证书的合法性,如果证书合法,客户端产生一段随机数,这个随机数就作为通信的密钥,我们称之为对称密钥,用公钥加密这段随机数,然后发送到服务器

服务器用密钥解密获取对称密钥,然后,双方就已对称密钥进行加密解密通信了

 

传输服务器的证书(公钥)时,被别人窃取走了怎么办?

当然服务器没有这么笨,传给客户端的证书是被加密了的,而且是由第三方权威机构CA的私钥加密证书,第三方权威机构CA的公钥维护于(存在于)每个浏览器(无论是中间的黑客、真正的请求者,还有服务器)中。这些有CA机构颁发的证书,都是有CA机构加密了的,客户端或者中间商收到这份CA颁发的证书,都可以解密出服务器的公钥。

 

那么,最开始https请求到服务器给的证书(CA机构颁发的)过程中,证书到达客户端的路上被黑客拦截了,中间的 "笨笨的黑客" 向CA申请了一套自己的证书,把自家的证书发回给那个客户端,然后通过自己申请的那一套证书的私钥解密出客户端发出的信息,通过拦截下来的服务器端的公钥解密服务端返回给客户端的信息,在中间的位置窃取信息。当然这种事情不会发生,权威的CA机构颁发的证书是有数字签名的,任何组织申请的证书都有对应的证书编码,证书是颁发给谁的,使用者是谁,这些申请者的详细信息都是被记录在案,客户端接收到这份证书后会计算出证书数字签名,证书的使用者对不上也是没有用的。

这样,通过权威的CA机构和证书的数字签名,客户端和服务器端之间建立起的对话秘钥就不会被别人窃取走,即时中间的第三者拿到了服务器的公钥也没有办法解密用服务器公钥加密的内容。

 

Guess you like

Origin www.cnblogs.com/magic-sea/p/11348944.html