简单粗暴系列之HTTPS原理

作者: 圣迪 | 来源:发表于2015-11-04 23:22 被阅读16668次

一、开篇
  简单粗暴,本文来聊聊HTTPS。
  啥是HTTPS? 说白了就是HTTP Over SSL。HTTP呢,就是我们平时上网时,浏览器和服务器之间传输数据的一项协议。普通情况下,浏览器发送的请求会经过若干个网络中间节点,最后到达服务器;然后服务器又将请求的数据经过若干个网络中间节点发送回给浏览器,这时候浏览器就能够显示我们想要看到的页面。
  这个过程中,其实并没有存在什么太大的问题。问题出在,如果我们需要在网页上输入一些敏感信息,如我们的银行卡账号和密码,发送给服务器,就会在中间节点中存在泄漏的风险。HTTPS就是为了保障传输过程中的安全目的而生的。HTTPS保证了数据仅仅只在发送方和目的方双方可见,而对中间任一一个节点都不可见。这是怎么实现的?我们来慢慢看。

二、故事
我们首先来看一个故事:
1)流程
  有两个大师,他们需要经常交流研究心得,因此需要频繁地进行相互信件往来。在信件往来的过程中,我们假设发送方是大师A,而目的方是大师B。A想告诉B一些研究的最新成果,于是将相关的研究成果写成了一封信,从邮局邮寄给B。这封信通过邮局的若干个快递员,最终到达了B的手里。这样就形成了一个最典型的数据传输过程。

2)加密、解密、密钥、加密算法
  现在,大师A觉得,我写的这封信,要是哪个快递员打开看过了,我的最新研究成果不就泄漏了吗?要是这个快递员拿去卖钱我半辈子努力不就白费了?于是乎大师A就想了个办法,在书写的过程中,每个字符都加4。如字符A就写成E,字符B就写成F,以此类推。大师B收到了信件后,再把每个字符都减去4,这样就可以正确得到大师A想传递的研究成果的内容。而最重要的是,即使快递员在中间拆开信件,如果不知道4这个数字,是无法正确的到信件内容的。
  我们将大师A每个字符加4的过程,叫做“加密”;大师B每个字符减4的过程,叫做“解密”;而数字4,就是我们常说的密钥。而这种加密算法,名为凯撒算法。

3)证书
  就这样,平安地度过了一段时间,直到突然有一天大师B收到一封来自于大师A的信,但是大师B使用之前的方式怎么也明白不了大师A说的是什么。于是电话询问大师A关于这封信的内容。结果大师A说,这不是我写的啊。这才发现,大师B收到的是一封伪造大师A的来信。为防止以上事情再次发生,大师A与大师B商量说,以后每封信上,我都会签上自己特有的签名,并带上相关内容的HASH值。
  HASH值用来校验这封信是否有被篡改过,而签名类似于指纹,用来标示这封信是否真实来自于指纹上所指向的人。一般来说,签名的内容中会包含这封信的发件方地址等信息。大师B收到信件后第一时间通过内容的HASH值来校验信件的内容长度;通过签名来校验发件方地址和指纹信息是否匹配。只有全部匹配才继续用之前的密钥进行解密操作。
  这些标明了大师A身份信息等信息的签名,就是我们常说的证书。
  经过以上的故事,我们大致明白了密钥、加密解密、算法等必要的知识了。而HTTPS的过程其实和这个类似,只不过多了一些数学的描述。

三、HTTPS工作原理
  HTTPS工作在客户端和服务器端之间。以上故事中,客户端可以看作为大师A,服务器端可以看作为大师B。客户端和服务器本身都会自带一些加密的算法,用于双方协商加密的选择项。
1、客户端首先会将自己支持的加密算法,打个包告诉服务器端。
2、服务器端从客户端发来的加密算法中,选出一组加密算法和HASH算法(注,HASH也属于加密),并将自己的身份信息以证书的形式发回给客户端。而证书中包含了网站的地址,加密用的公钥,以及证书的颁发机构等;
  这里有提到公钥的概念是故事中没有的。我们常见的加密算法一般是一些对称的算法,如凯撒加密;对称算法即加密用的密钥和解密用的密钥是一个。如故事中的密钥是4。还有一种加密解密算法称之为非对称算法。这种算法加密用的密钥(公钥)和解密用的密钥(私钥)是两个不同的密钥;通过公钥加密的内容一定要使用私钥才能够解密。
  这里,服务器就将自己用来加密用的公钥一同发还给客户端,而私钥则服务器保存着,用户解密客户端加密过后的内容。

3、客户端收到了服务器发来的数据包后,会做这么几件事情:
 1)验证一下证书是否合法。一般来说,证书是用来标示一个站点是否合法的标志。如果说该证书由权威的第三方颁发和签名的,则说明证书合法。
 2)如果证书合法,或者客户端接受和信任了不合法的证书,则客户端就会随机产生一串序列号,使用服务器发来的公钥进行加密。这时候,一条返回的消息就基本就绪。
 3)最后使用服务器挑选的HASH算法,将刚才的消息使用刚才的随机数进行加密,生成相应的消息校验值,与刚才的消息一同发还给服务器。

4、服务器接受到客户端发来的消息后,会做这么几件事情:
 1)使用私钥解密上面第2)中公钥加密的消息,得到客户端产生的随机序列号。
 2)使用该随机序列号,对该消息进行加密,验证的到的校验值是否与客户端发来的一致。如果一致则说明消息未被篡改,可以信任。
 3)最后,使用该随机序列号,加上之前第2步中选择的加密算法,加密一段握手消息,发还给客户端。同时HASH值也带上。

5、客户端收到服务器端的消息后,接着做这么几件事情:
 1)计算HASH值是否与发回的消息一致
 2)检查消息是否为握手消息

6、握手结束后,客户端和服务器端使用握手阶段产生的随机数以及挑选出来的算法进行对称加解密的传输。
  为什么不直接全程使用非对称加密算法进行数据传输?这个问题的答案是因为非对称算法的效率对比起对称算法来说,要低得多得多;因此往往只用在HTTPS的握手阶段。
  以下是我们一些经常使用的加密算法,是不是有熟悉的味道?
   非对称加密算法:RSA, DSA/DSS
   对称加密算法: AES, 3DES
   HASH算法:MD5, SHA1, SHA256

这就是HTTPS的基本原理,如果没有简单粗暴,请告诉我,以帮助我持续改进;如果真的简单粗暴,请告诉有需要的人,大家共同进步。

相关文章

网友评论

  • ZzzBj:证书合法验证那块如果能再说明一下就好了,因为证书也可能是伪造的,验证证书合法性的过程是怎么样的呢?
  • 5458f86ed47b:确实简单粗暴,要是有配图就更完美了:smile:
  • Levi段玉磊:通过这篇文,懂了一个道理,在看枯燥的书以及理论之前,最后能有个例子来引人入胜,例如大师书信的例子,然后再看枯燥的书就不再枯燥了。幽默感也是起到这种作用,不过没有类比论证好用。
  • 北你妹的风:的确通俗易懂,简单粗暴
  • 人话博客:好多版本。我听到的版本就有点不一样。
    大致过程。
    1. 客户端发发送 HTTPS 请求,附带自己的加密算法以及 TLC/SSL 版本。
    2. 服务器接受到客户端的请求,发送自己的证书给客户端(没有发送随机数)
    3. 客户端检查证书是否合法?如果合法,生成一个随机数,然后使用公钥对随机数进行加密。(这个随机数,就是之后传输数据之间使用的对称加密的秘钥)
    4. 服务器拿到了这个加密后的随机数,然后使用私钥对其进行解密,得到对称加密秘钥。
    5.之后,客户端和服务器之间就使用这个秘钥进行对称加密数据传输。
    圣迪:@CodeForFood “简单粗暴”,告诉你怎么会事儿而已。完整的,权威的SSL->TLS 都会有些不同。
    如果需要如此详细,建议查看RFC,这是最权威的
  • EvanJq:简单粗暴
  • CloudStrife:很好,非常的简单粗暴。理解了!
  • winwill2012:写得非常棒!!另外再给大家推荐一篇
    http://qifuguang.me/2017/03/25/%E7%9C%8B%E5%AE%8C%E8%BF%98%E4%B8%8D%E6%87%82HTTPS%E6%88%91%E7%9B%B4%E6%92%AD%E5%90%83%E7%BF%94/
    图文并茂,比较通俗
    f123d21a3107:网址不对,看不了
  • 流浪猫121:如果服务器用私钥解密,那服务器发给客户端的数据,客户端用什么解密呢
    圣迪:@流浪猫121 公钥、私钥 是一对,可以看看非对称加密的原理
  • 865e2dd08c3d:"2)如果证书合法,或者客户端接受和信任了不合法的证书,则客户端就会随机产生一串序列号,使用服务器发来的公钥进行加密。这时候,一条返回的消息就基本就绪。"
    ==============================================================
    关于这里的说法: "一条返回的消息就基本就绪" 说的什么? 是前面 "则客户端就会随机产生一串序列号,使用服务器发来的公钥进行加密" 这里生成的? 随机序列号生成的消息? 还是说单独的一条握手消息? ~~~
  • 鬼谷门生:大神,请问服务端从包中选中一组加密算法和HASH算法,这里的HASH算法是从客服端打包过来的还是客户端自己选择的一种算法啊,谢谢!
    寒雪无痕: @鬼谷门生 客户端和服务端都有自己的加密和加密算法,至于双方选择那一组加解密算法,那就看使用公钥加密后的摘要内容实际意义了了。具体的你可以去研究下“密码学概论”这本书。
  • 6cc787a7dc9c:请问第四步的HASH值是什么..
    圣迪:@kolaker hash检验,如md5 等签名算法
  • 中隐_隐于市:简单粗暴 但 生动形象
  • bf9f5f1100b5:你好,之前看了您的网络框架 DRDNetworking,受益良多,有个问题请教一下:

    - (void)_sendSingleAPIRequest:(DRDBaseAPI *)api
    withSessionManager:(AFHTTPSessionManager *)sessionManager
    andCompletionGroup:(dispatch_group_t)completionGroup {
    NSParameterAssert(api);
    NSParameterAssert(sessionManager);

    __weak typeof(self) weakSelf = self;
    NSString *requestUrlStr = [self requestUrlStringWithAPI:api];
    id requestParams = [self requestParamsWithAPI:api];
    NSString *hashKey = [NSString stringWithFormat:@"%lu", (unsigned long)[api hash]];

    if ([self.sessionTasksCache objectForKey:hashKey]) {
    NSDictionary *userInfo = @{
    NSLocalizedDescriptionKey : @"Request send too fast, please try again later"
    };
    NSError *cancelError = [NSError errorWithDomain:NSURLErrorDomain
    code:NSURLErrorCancelled
    userInfo:userInfo];
    [self callAPICompletion:api obj:nil error:cancelError];
    return;
    }


    这段代码中是不是少了

    if (completionGroup) {
    dispatch_group_leave(completionGroup);
    }

    呢?

    谢谢
    圣迪:@RomeoLeft 非常感谢您!

    的确如您所示,这里少了一个completionGroup.

    已提PR并感谢 :smile:

    有更多意见欢迎多提

本文标题:简单粗暴系列之HTTPS原理

本文链接:https://www.haomeiwen.com/subject/cctchttx.html