HTTPS中的数字证书认证过程解析

RSA非对称加密的2个用途:加密和签名

加密(防窃听)

RSA非对称加密会用到一对密钥,分别称为公钥和私钥,公钥加密之后的数据可以通过私钥来进行解密,私钥加密的数据也同样可以用对应的公钥进行解密。在web数据传输过程中,由于客户端和服务器端是多对一的关系,因此可以让所有的客户端持有相同的公钥,服务器持有私钥,这样一来就能方便地实现数据的加密传输。

在网络传输过程中,一旦客户端发送的用公钥加密过的数据被第三方截获,由于第三方没有服务器上的私钥,因此无法对客户端发送的加密数据进行解密从而获得明文,这样就起到了防窃听的作用。

签名(防篡改)

由于私钥只在某一个体手中,因此可以通过这一点来进行身份识别。比如用户A和B分别有一对密钥中的私钥和公钥,现在A向B发送消息abc,可进行如下操作:A用私钥对该文本进行加密之后变成密文#¥%,并附加上原文,组合成文本#¥%:abc(冒号起分隔作用,并无其他含义,具体实现中可自行处理)一起发送,B接收到该文本之后利用公钥对密文进行解密,将得到的解密后文本与传送过来的文本abc之间进行比对,如果一切正常,那么公钥解密之后的文本就是私钥加密之前的文本abc,比对结果一致,因此可以说明这段abc文本确实是A发送过来的,因为只有A才有对文本进行签名的私钥。能得到这个结论的前提是——A所用的私钥跟B所用的公钥确实是一对。

假如在传送途中有人篡改了abc,改成aaa,由于中间人没有A所持有的私钥,因此无法对篡改之后的数据生成新的正确签名,那么B在收到数据之后用公钥进行解密,再与传送的文本进行比对的话就不会一致。或者中间人篡改了数据之后用另一私钥对篡改之后的数据进行签名,同样由于B没有中间人的私钥对应的公钥,因此比对也不会一致。记住一点:B的公钥所对应的私钥只在A的手中,因此比对一致就说明该文本来自A。

HTTPS如何保证安全?

简要说明一下,假设现在有一对密钥(公钥和私钥),如果客户端持有公钥,服务器持有该公钥对应的私钥,那么根据我们前面论述的RSA非对称加密的作用,客户端和服务器通过这一对密钥进行数据的加密传输不会有问题,即数据不会被第三方窃听。

如何保证客户端所持有的公钥就是某合法服务器声明的公钥?

即服务器端如何安全地把它的公钥下发给客户端(这里的客户端一般指的是浏览器)。如果不能保证这一点,那么客户端发送的信息就有可能存在被窃听的风险,因为客户端用此公钥加密的数据可以被其对应的私钥拥有者获取,而该私钥并不在客户端所认为的服务器上。 相当于攻击者给了客户端一个它自己的公钥,让客户端认为这个公钥是某合法服务器的公钥,于是客户端用此公钥对数据进行加密传送,攻击者将此加密数据截获并用自己的私钥进行解密。由于客户端用来加密的公钥就是攻击者给客户端的,因此攻击者能够获取解密之后的明文,从而窃取客户端的信息。

可采用一个权威机构进行证书的颁发,所谓证书就是包含了服务器声明的公钥以及组织名称等信息,这里我们只考虑最关键的公钥信息。该权威机构会对申请证书的组织进行审核,确保其身份合法,然后将服务器公钥信息发布给客户端,客户端可利用该公钥与对应的服务器进行通信。整个过程可归纳为以下几步:

1.服务器生成一对密钥,私钥自己留着,公钥交给数字证书认证机构(CA)
2.CA进行审核,并用CA自己的私钥对服务器提供的公钥进行签名(参照上文RSA签名)
3.客户端从CA获取证书(即获取服务器端公钥),从而拿到了服务器端的公钥。

如何保证客户端拿到的证书确实是权威机构(CA)颁发的证书?

要保证这一点,上面第2步中的CA用自己的私钥对服务器提供的公钥进行签名就起到了作用。为确保该证书确实是CA颁发的,因此需要用到上面论述的RSA签名防篡改的功能。客户端需要用CA的公钥对签名的证书进行验证,比对一致,说明该服务器公钥确实是CA颁发的。(不知道此时读者是否能想到CA发给客户端的证书信息不只有服务器的公钥,还有CA对此公钥进行的签名。)而CA又作为权威机构保证该公钥的确是服务器端提供的,从而可以确认该证书中的公钥确实是合法服务器端提供的。

那么问题又来了:

如何保证客户端所持有的CA公钥确实是CA的私钥所对应的公钥?

也就是说CA的公钥必须要安全地转交给客户端,这真是一个先有鸡还是先有蛋的问题。幸运的是,CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是,CA的公钥就安全地转交给了客户端(浏览器)。

也许你又要问了,万一我的浏览器就有问题呢?那我只能说:兄弟,少用盗版,实在不行,卸载重装吧。好吧,开个玩笑_

由此可见:所谓的安全的HTTP,其实也是要建立在信任的机制上。

总结

整个过程涉及2对公私密钥对:

  • 一对由服务器产生,用于加密
  • 一对由CA产生,用于签名。

整个过程还涉及2个信任:

  • 客户端信任CA颁发的证书中的公钥就是合法服务器的公钥
  • 客户端信任浏览器内置的CA公钥就是与CA私钥对应的公钥

最后要说明的是,由于非对称加密算法的效率不高,非对称加密在HTTPS中只是用来对对称加密密钥进行协商的过程才使用,在两端协商完对称加密的密钥之后,数据的加密传输均采用对称加密的方式。

您的关注是我不断创作的动力源泉!期待认识更多的朋友,一起交流Java相关技术栈,共同进步!阅读更多技术文章,可关注我的公众号:codecrazy4j

阿斌哥的博客

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,921评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,635评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,393评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,836评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,833评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,685评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,043评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,694评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,671评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,670评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,779评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,424评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,027评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,984评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,214评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,108评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,517评论 2 343

推荐阅读更多精彩内容