由HTTPS和HTTP的区别引出的总结

本文主要是介绍由HTTPS和HTTP的区别引出的总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

今天看到一个面试题：HTTPS和HTTP的区别，虽然自己在项目中已经支持https，但是其原理有点模糊，今天做一下总结
问题：　HTTPS和HTTP的区别主要如下：
　　1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

由这个问题引发出：https是什么？采用什么机制
1. HTTPS
其实HTTPS从最终的数据解析的角度，与HTTP没有任何的区别，HTTPS就是将HTTP协议数据包放到SSL/TSL层加密后，在TCP/IP层组成IP数据报去传输，以此保证传输数据的安全；而对于接收端，在SSL/TSL将接收的数据包解密之后，将数据传给HTTP协议层，就是普通的HTTP数据。HTTP和SSL/TSL都处于OSI模型的应用层。从HTTP切换到HTTPS是一个非常简单的过程，在做具体的切换操作之前，我们需要了解几个概念：

SSL/TSL
关于SSL/TSL，阮一峰的两篇博客文章做了很好的介绍：
• SSL/TLS协议运行机制的概述
• 图解SSL/TLS协议

SSL/TLS协议的基本思路是采用公钥加密法；SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成”对话密钥”。
（3） 双方采用”对话密钥”进行加密通信。
上面过程的前两步，又称为”握手阶段”（handshake）。
2、握手阶段的详细过程
“握手阶段”涉及四次通信，我们一个个来看。需要注意的是，”握手阶段”的所有通信都是明文的。

4.1 客户端发出请求（ClientHello）
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数，稍后用于生成”对话密钥”。
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。

4.2 服务器回应（SeverHello）
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成”对话密钥”。
（3） 确认使用的加密方法，比如RSA公钥加密。
（4） 服务器证书。
数字证书：该证书包含了公钥等信息，一般是由服务器发给客户端，接收方通过验证这个证书是不是由信赖的CA签发，或者与本地的证书相对比，来判断证书是否可信；假如需要双向验证，则服务器和客户端都需要发送数字证书给对方验证；
4.3 客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

三个随机数：这三个随机数构成了后续通信过程中用来对数据进行对称加密解密的“对话密钥”。
首先客户端先发第一个随机数N1，然后服务器回了第二个随机数N2（这个过程同时把之前提到的证书发给客户端），这两个随机数都是明文的；而第三个随机数N3（这个随机数被称为Premaster secret），客户端用数字证书的公钥进行非对称加密，发给服务器；而服务器用只有自己知道的私钥来解密，获取第三个随机数。只有，服务端和客户端都有了三个随机数N1+N2+N3，然后两端就使用这三个随机数来生成“对话密钥”，在此之后的通信都是使用这个“对话密钥”来进行对称加密解密。因为这个过程中，服务端的私钥只用来解密第三个随机数，从来没有在网络中传输过，这样的话，只要私钥没有被泄露，那么数据就是安全的。
加密通信协议：就是双方商量使用哪一种加密方式，假如两者支持的加密方式不匹配，则无法进行通信；
有个常见的问题，关于随机数为什么要三个？只最后一个随机数N3不可以么？
这是由于SSL/TLS设计，就假设服务器不相信所有的客户端都能够提供完全随机数，假如某个客户端提供的随机数不随机的话，就大大增加了“对话密钥”被破解的风险，所以由三组随机数组成最后的随机数，保证了随机数的随机性，以此来保证每次生成的“对话密钥”安全性。

4.4 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

3、支持https的代码
3.1NSURLConnection支持方式
验证证书的API
相关的Api在Security Framework中，验证流程如下：
1). 第一步，先获取需要验证的信任对象(Trust Object)。这个Trust Object在不同的应用场景下获取的方式都不一样，对于NSURLConnection来说，是从delegate方法-connection:willSendRequestForAuthenticationChallenge:回调回来的参数challenge中获取([challenge.protectionSpace serverTrust])。
2). 使用系统默认验证方式验证Trust Object。SecTrustEvaluate会根据Trust Object的验证策略，一级一级往上，验证证书链上每一级数字签名的有效性（上一部分有讲解），从而评估证书的有效性。
3). 如第二步验证通过了，一般的安全要求下，就可以直接验证通过，进入到下一步：使用Trust Object生成一份凭证([NSURLCredential credentialForTrust:serverTrust])，传入challenge的sender中([challenge.sender useCredential:cred forAuthenticationChallenge:challenge])处理，建立连接。
4). 假如有更强的安全要求，可以继续对Trust Object进行更严格的验证。常用的方式是在本地导入证书，验证Trust Object与导入的证书是否匹配。更多的方法可以查看Enforcing Stricter Server Trust Evaluation，这一部分在讲解AFNetworking源码中会讲解到。
5). 假如验证失败，取消此次Challenge-Response Authentication验证流程，拒绝连接请求。
ps: 假如是自建证书的，则会跳过第二步，使用第三部进行验证，因为自建证书的根CA的数字签名未在操作系统的信任列表中。
iOS授权验证的API和流程大概了解了，下面，我们看看在NSURLConnection中的代码实现：

// Now start the connection
NSURL * httpsURL = [NSURL URLWithString:@"https://www.google.com"];
self.connection = [NSURLConnection connectionWithRequest:[NSURLRequest requestWithURL:httpsURL] delegate:self];//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {//1)获取trust objectSecTrustRef trust = challenge.protectionSpace.serverTrust;SecTrustResultType result;//2)SecTrustEvaluate对trust进行验证OSStatus status = SecTrustEvaluate(trust, &result);if (status == errSecSuccess &&(result == kSecTrustResultProceed ||result == kSecTrustResultUnspecified)) {//3)验证成功，生成NSURLCredential凭证cred，告知challenge的sender使用这个凭证来继续连接NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];} else {//5)验证失败，取消这次验证流程[challenge.sender cancelAuthenticationChallenge:challenge];}
}
/*上面是代码是通过系统默认验证流程来验证证书的。假如我们是自建证书的呢？这样Trust Object里面服务器的证书因为不是可信任的CA签发的，所以直接使用SecTrustEvaluate进行验证是不会成功。又或者，即使服务器返回的证书是信任CA签发的，又如何确定这证书就是我们想要的特定证书？这就需要先在本地导入证书，设置成需要验证的Anchor Certificate(就是根证书)，再调用SecTrustEvaluate来验证。代码如下*/
//先导入证书
NSString * cerPath = ...; //证书的路径
NSData * cerData = [NSData dataWithContentsOfFile:cerPath];
SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)(cerData));
self.trustedCertificates = @[CFBridgingRelease(certificate)];
//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {//1)获取trust objectSecTrustRef trust = challenge.protectionSpace.serverTrust;SecTrustResultType result;//注意：这里将之前导入的证书设置成下面验证的Trust Object的anchor certificateSecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)self.trustedCertificates);//2)SecTrustEvaluate会查找前面SecTrustSetAnchorCertificates设置的证书或者系统默认提供的证书，对trust进行验证OSStatus status = SecTrustEvaluate(trust, &result);if (status == errSecSuccess &&(result == kSecTrustResultProceed ||result == kSecTrustResultUnspecified)) {//3)验证成功，生成NSURLCredential凭证cred，告知challenge的sender使用这个凭证来继续连接NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];} else {//5)验证失败，取消这次验证流程[challenge.sender cancelAuthenticationChallenge:challenge];}

3.2 NSURLSession支持https

#import "ViewController.h"@interface ViewController ()<NSURLSessionDelegate,NSURLSessionDataDelegate>
@property (nonatomic, strong) NSURLSession *session;// 自定义会话
@end@implementation ViewController- (void)viewDidLoad {[super viewDidLoad];// Do any additional setup after loading the view, typically from a nib.
}- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {NSURL *url = [NSURL URLWithString:@"https://mail.itcast.cn"];[[self.session dataTaskWithURL:url] resume];
}//    NSURLSessionAuthChallengeUseCredential = 0, 使用（信任）证书
//    NSURLSessionAuthChallengePerformDefaultHandling = 1, 默认，忽略
//    NSURLSessionAuthChallengeCancelAuthenticationChallenge = 2,   取消
//    NSURLSessionAuthChallengeRejectProtectionSpace = 3,      这次取消，下载次还来问// 工作中直接复制这一段代理Ok了
- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challengecompletionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * __nullable credential))completionHandler {NSLog(@"%@",challenge.protectionSpace);// 如果是请求证书信任，我们再来处理，其他的不需要处理if (challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust) {NSURLCredential *cre = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];// 调用blockcompletionHandler(NSURLSessionAuthChallengeUseCredential,cre);}
}- (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveData:(NSData *)data {NSLog(@"%@",[[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding]);
}//- (void)demo:(void(^)())block {
//    block();
//}- (NSURLSession *)session {if (_session == nil) {_session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:nil];}return _session;
}@en

这篇关于由HTTPS和HTTP的区别引出的总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---