You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3)签发证书:如信息审核通过,CA 机构会向申请者签发认证文件:证书。
证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。
签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA 的私钥对信息摘要进行加密,密文即签名。(图一中生成 server.crt)
5)client验证证书:client 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任 CA 的证书信息(包含公钥),如果 CA 不被信任,则找不到对应 CA 的证书,证书也会被判定非法。(图一中 check 可选,我们可以选择不验证服务器证书的有效性)
6)秘钥协商:验证通过后,server 和 client 将进行秘钥协商。接下来 server 和 client 会采用对称秘钥加密。(对称加密时间性能优)(图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程)
提问
有人的地方就有江湖,有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。
Q1: CA 介绍
CA: 证书授权中心 (certificate authority)
它呢,类似于国家出入境管理处一样,给别人颁发护照;
也类似于国家工商管理局一样,给公司/企业颁发营业执照。
为了让服务端的公钥被大家信任,服务端的证书都是由 CA (Certificate Authority,证书认证机构)签名的,CA 就是网络世界里的公安局、公证中心,具有极高的可信度,所以由它来给各个公钥签名,信任的一方签发的证书,那必然证书也是被信任的。
在 HTTP 里面,证书都是签发给域名持有人的。
CA 签发证书的过程:
1)申请认证:服务器需自己生成公钥私钥对 pub_svr & pri_svr,同时根据 pub_svr 生成请求文件 csr,提交给 CA 机构,csr 中含有公钥、组织信息、个人信息(域名)等信息。(图一中 server.req 就是 csr 请求文件)
2)审核信息:CA 机构通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等。
3)签发证书:如信息审核通过,CA 机构会向申请者签发认证文件:证书。
证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。
签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA 的私钥对信息摘要进行加密,密文即签名。(图一中生成 server.crt)
4)返回证书:client 如果请求验证服务器,服务器需返回证书文件。(图一中 handshake 传回 server.crt)
5)client验证证书:client 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任 CA 的证书信息(包含公钥),如果 CA 不被信任,则找不到对应 CA 的证书,证书也会被判定非法。(图一中 check 可选,我们可以选择不验证服务器证书的有效性)
6)秘钥协商:验证通过后,server 和 client 将进行秘钥协商。接下来 server 和 client 会采用对称秘钥加密。(对称加密时间性能优)(图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程)
7)数据传输:SSL server 和 SSL client 采用对称秘钥加密解密数据。
————————————————
版权声明:本文为CSDN博主「ustccw」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ustccw/article/details/76691248
Q1:数字证书
数字证书是由权威的CA(Certificate Authority)机构给服务端进行颁发,CA机构通过服务端提供的相关信息生成证书,证书内容包含了持有人的相关信息,服务器的公钥,签署者签名信息(数字签名)等,最重要的是公钥在数字证书中。
一个证书中含有三个部分:"证书内容,散列算法,加密密文",证书内容会被散列算法hash计算出hash值,然后使用CA机构提供的私钥进行RSA加密。
HTTPS 的实现原理
HTTPS 在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段。
HTTPS的整体过程分为证书验证和数据传输阶段,具体的交互过程如下:
证书验证阶段(又称TLS握手阶段)
数据传输阶段
为什么数据传输是用对称加密?
首先,非对称加密的加解密效率是非常低的,而 http 的应用场景中通常端与端之间存在大量的交互,非对称加密的效率是无法接受的;
另外,在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密,所以 HTTPS 中内容传输加密采取的是对称加密,而不是非对称加密。
浏览器拿到了服务端的数字证书后,要怎么校验该数字证书是真实有效的呢?
数字证书的作用,是用来认证公钥持有者的身份,以防止第三方进行冒充。
说简单些,证书就是用来告诉客户端,该服务端是否是合法的,因为只有证书合法,才代表服务端身份是可信的。
我们用证书来认证公钥持有者的身份(服务端的身份),那证书又是怎么来的?又该怎么认证证书呢?
为了让服务端的公钥被大家信任,服务端的证书都是由 CA (Certificate Authority,证书认证机构)签名的,CA 就是网络世界里的公安局、公证中心,具有极高的可信度,所以由它来给各个公钥签名,信任的一方签发的证书,那必然证书也是被信任的。
HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器,而 HTTPS 协议主要解决的便是网络传输的安全性问题。
首先我们假设不存在认证机构,任何人都可以制作证书,这带来的安全风险便是经典的“中间人攻击”问题。
The text was updated successfully, but these errors were encountered: