最近研究了一番 https 的知识,总结如下,为了更好的让零基础用户理解,下面用最直白的话描述,可能不够严谨,但能帮助理解。
水平有限,不足之处,还请高手多多指点!
在早期,客户端(这里指浏览器)和服务器之间(这里指 http 服务器)传输数据是明文传输的,这就是 http 协议。这有个缺点,任何人都可以通过抓包拦截网络传输中的数据包,甚至拦截后重发,这很不安全。
后来有聪明的人提出了加密,所谓加密就是通过一个密钥(通常是一个密码一样的字符串,通常由浏览器生成),然后通过某种算法对数据进行打乱,只有知道密钥的人才能解密这段数据,这通常叫做对称加密。
但,又有聪明的人提出了,想法很好,但你的密钥怎么告诉服务器,密钥传输中也可能被拦截,这样,别也知道你的秘钥了,加密还有什么用。
这就很尴尬了,后来又有一个更聪明的人,提出了一种加密算法,就是秘钥不是有一个,而是两个,一个加密,另一个解密,这两个秘钥通常称为公钥和私钥,而这种加密方式称为非对称加密,通常公钥用于加密,私钥用于解密,但在签名场景则通常私钥加密消息摘要,生成签名,而公钥解密签名,获取消息摘要。总之,有了这种加密算法,就可以用这种加密算法把对称加密密钥进行加密后再传给服务器,这样就解决了对称密钥被窃取的风险。
但问题又来了,怎么把私钥和公钥传给服务器或者说两者该怎么协商呢,仍然没能解决上面说的秘钥被拦截问题,而浏览器也不是针对一家服务器,不可能事先与你协商秘钥。
后来,又有大聪明提出了一个想法,通过第三方机构,没错,这个有点像支付宝担保支付,找一家大家都信任的第三方进行担保,这就是所谓的第三方证书颁发机构,那么这个颁发的证书中包含了一系列信息,包括个人或组织信息,域名,第三方机构等信息,当然也包含公钥,这就是所谓的安全证书。
当你想搭建一个 https 的网站时,你先要去第三方机构去申请安全证书(通常通过证书颁发网站申请),申请前先用 OpenSSL 生成私钥,然后用这个私钥生成 CSR,CRS 中包含公钥以及关于您的域名、组织信息等,然后把 CSR 发给颁发证书网站,然后安全证书网站会对你的个人或组织信息及域名等进行验证,验证通过后,会生成一个安全证书给你,证书中包含证书公钥和 CA 签名(签名主要为了防止证书被篡改)。注意,有些第三方机构(比如某云平台)为了降低用户使用难度可能会自动帮你生成 CSR 文件,你只需要填写资料申请,验证域名,颁发,下载证书相关文件即可。这个相关文件是因为下载的文件里包含了证书和私钥,没错,云平台帮你生成了私钥,严格意义上说这不够安全,当然,一般这个文件通常只有用户自己的账号才能访问,相对是安全的,要说不安全那你的文件还放在平台呢。
然后,你需要把证书(通常是 crt 文件)和私钥(通常是 key 文件)放到服务器,并在 http 服务器中进行配置,这样,当浏览器请求你的网站时,服务器会把证书及证书公钥发送给浏览器。浏览器拿到证书后,会做两件事,第一,根据证书去验证证书的可靠性,包括机构是否受信任,证书是否过期,是否和域名匹配等,第二件事,如果第一件事验证通过,则随机生成一个对称加密的密钥,然后用证书公钥进行加密,然后发送给服务器,由于这个密钥被非对称加密了,除了拥有证书私钥的人(即服务器外),无人能解密,这样就保证了传输的安全性。
然后,服务器收到浏览器发送过来的密钥后,通过证书私钥进行解密,然后就拿到对称密钥了。然后服务器发送数据给浏览器时就可以通过这个对称密钥进行加密了,而浏览器也可以通过这个密钥进行解密,自己发过去的密钥自己自然知道了。这样就保证了数据传输过程中的安全。
有时你也可能或见到 .p12 文件,它包含了证书和私钥,通常会使用密码进行加密,以增加安全性。这意味着需要提供密码才能从中提取证书和私钥。这种格式的文件通常用于需要将证书和私钥一起打包和分发的场景,例如移动应用开发、桌面应用程序配置等。
下面是 https 验证过程示意图
问题列表:
-
浏览器是怎么验证证书是可靠的呢?
浏览器预先安装一系列受信任机构的根证书,这些根证书是颁发机构自己生成的用于验证自己身份的证书。当你向颁发机构申请证书时,颁发机构会用根证书或中间证书(由根证书直接或间接签名的证书)给你的证书进行签名。而当浏览器访问您的网站时,它会检查你的证书是否由一个已知的、受信任的根证书所签名。这样就形成了一条信任链,从最终用户证书到中间证书再到根证书。
-
什么是签名?什么是验签?消息摘要为什么加密?
签名是防止数据被篡改的手段。比如,你需要给浏览器发送数据,在发送前,你先通过 hash 算法,给你的数据生成消息摘要(消息摘要就是把数据生成固定长度的字符串,每次生成都一样),然后用私钥给消息摘要进行加密,生成签名,发送时,把数据和签名及公钥一起发送,浏览器拿到这些数据后,通过公钥对签名进行解密,获取消息摘要,然后再通过对数据进行生成消息摘要,然后对比这两者的消息摘要是否一致,来确认数据是否被篡改。
这里细心的朋友发现,这公钥是公开的,任何人都可以解密签名获取摘要,还有什么用?这里主要是消息摘要加密后,即使窃取者解密了,但他无法篡改数据,因为篡改了数据后,窃取方没有私钥,无法生成新的签名,如果附加假的签名或用原签名,验签都无法通过。而如果摘要不加密,那么窃取者可以篡改数据,并附加新的摘要,而接收方无法知道数据是否被篡改,以及是否发送方发送的数据,无法保证数据的安全。
-
我可以自己生成根证书吗?
是的,你可以通过 OpenSSL 给自己生成根证书,然后再给服务器生成证书,然后用你的根证书签名,然后把根证书导入浏览器即可。
-
既然公钥和私钥都可以加密解密,公钥和私钥可以互换吗?比如私钥公开,公钥保密。
不可以互换,因为私钥可以生成公钥,如果私钥公开,那么别人通过私钥可以生成公钥,因为私钥和公钥一一对应的,多次生成公钥的结果是一样的,这样就相当于你公钥和私钥都公开了。
-
既然公钥和私钥可以加密解密了,传输数据为什么不用公钥和私钥加密,还加个对称加密干嘛?
因为性能问题,对称加密性能更高,这样既保证了数据的安全传输,又不会因为加密过程而大幅增加计算负担。
-
对称加密和非对称加密算法有哪些?
对称加密算法 DES (Data Encryption Standard) AES (Advanced Encryption Standard) 3DES (Triple DES) RC4 (Rivest Cipher 4) Blowfish 非对称加密算法 RSA (Rivest-Shamir-Adleman) DSA (Digital Signature Algorithm) Diffie-Hellman Key Exchange ECC (Elliptic Curve Cryptography)
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于