IOS 网络协议(一) 自签名证书HTTPS文件上传下载(上)html
IOS 网络协议(一) 自签名证书HTTPS文件上传下载(下)web
IOS音视频(四十三)AVFoundation 之 Audio Session安全
IOS音视频(四十四)AVFoundation 之 Audio Queue Services服务器
IOS音视频(四十五)HTTPS 自签名证书 实现边下边播markdown
IOS 网络协议(一) 自签名证书HTTPS文件上传下载(上)session
最近因为项目须要实现IOS数据经过https实现与机器人端的文件传输功能。参考了不少资料,最终实现了一个文件传输功能,其中在https证书配置方面遇到了不少坑,写这篇文章一是对这段工做的总结,方便本身之后查阅,同时也但愿帮助到更多有一样需求的哥们,少走一点弯路,节省时间。
HTTP:是互联网上应用最为普遍的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可使浏览器更加高效,使网络传输减小。 HTTP有称为:超文本传输协议(HTTP,HyperText Transfer Protocol)全部的WWW文件都必须遵照这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种经过计算机处理文本信息的方法,并称之为超文本(hypertext),这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会(World Wide Web Consortium)和互联网工程工做小组(Internet Engineering Task Force )共同合做研究,最终发布了一系列的RFC,其中著名的RFC 2616定义了HTTP 1.1。
主要功能:
- HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可使浏览器更加高效,使网络传输减小。它不只保证计算机正确快速地传输超文本文档,还肯定传输文档中的哪一部分,以及哪部份内容首先显示(如文本先于图形)等。
- HTTP是客户端浏览器或其余程序与Web服务器之间的应用层通讯协议。在Internet上的Web服务器上存放的都是超文本信息,客户机须要经过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息,不只可用于Web访问,也能够用于其余因特网/内联网应用系统之间的通讯,从而实现各种应用资源超媒体访问的集成。
- 咱们在浏览器的地址栏里输入的网站地址叫作URL (Uniform Resource Locator,统一资源定位符)。就像每家每户都有一个门牌地址同样,每一个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级连接时,URL就肯定了要浏览的地址。浏览器经过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并翻译成漂亮的网页。
HTTP是一个客户端和服务器端请求和应答的标准(TCP)。客户端是终端用户,服务器端是网站。经过使用Web浏览器、网络爬虫或者其它的工具,客户端发起一个到服务器上指定端口(默认端口为80)的HTTP请求。(咱们称这个客户端)叫用户代理(user agent)。应答的服务器上存储着(一些)资源,好比HTML文件和图像。(咱们称)这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个中间层,好比代理,网关,或者隧道(tunnels)。尽管TCP/IP协议是互联网上最流行的应用,HTTP协议并无规定必须使用它和(基于)它支持的层。 事实上,HTTP能够在任何其余互联网协议上,或者在其余网络上实现。HTTP只假定(其下层协议提供)可靠的传输,任何可以提供这种保证的协议均可以被其使用。 一般,由HTTP客户端发起一个请求,创建一个到服务器指定端口(默认是80端口)的TCP链接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求,服务器(向客户端)发回一个状态行,好比"HTTP/1.1 200 OK",和(响应的)消息,消息的消息体多是请求的文件、错误消息、或者其它一些信息。HTTP使用TCP而不是UDP的缘由在于(打开)一个网页必须传送不少数据,而TCP协议提供传输控制,按顺序组织数据,和错误纠正。 经过HTTP或者HTTPS协议请求的资源由统一资源标示符(Uniform Resource Identifiers)(或者,更准确一些,URLs)来标识。
- 基于请求/响应模型的协议。请求和响应必须成对,先有请求后有响应
- http协议默认端口:80
- 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不一样。因为HTTP协议简单,使得HTTP服务器的程序规模小,于是通讯速度很快。
- 灵活:HTTP容许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 5 .无链接:无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开链接。采用这种方式能够节省传输时间。
- 无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息,则它必须重传,这样可能致使每次链接传送的数据量增大。另外一方面,在服务器不须要先前信息时它的应答就较快。
版本 | 产生时间 | 内容 | 发展示状 |
---|---|---|---|
HTTP/0.9 | 1991年 | 不涉及数据包传输,规定客户端和服务器之间通讯格式,只能GET请求 | 没有做为正式的标准 |
HTTP/1.0 | 1996年 | 传输内容格式不限制,增长PUT、PATCH、HEAD、 OPTIONS、DELETE命令 | 正式做为标准 |
HTTP/1.1 | 1997年 | 持久链接(长链接)、节约带宽、HOST域、管道机制、分块传输编码 | 2015年前使用最普遍 |
HTTP/2 | 2015年 | 多路复用、服务器推送、头信息压缩、二进制协议等 | 逐渐覆盖市场 |
HTTP/0.9 :只接受GET一种请求方法,没有在通讯中指定版本号,且不支持请求头。因为该版本不支持POST方法,所以客户端没法向服务器传递太多信息。 HTTP/1.0 :第一个在通讯中指定的版本号,至今被普遍采用,特别是在代理服务器中。 HTTP/1.1 :当前版本号,持久链接被默认采用,并能很好地配合代理服务器工做。还支持以管道方式在同时发送多个请求,以便下降线路负载,提升传输速度。 HTTP/2.0 正在开发中······
主要区别: 在同一个tcp的链接中能够传送多个HTTP请求和响应. 多个请求和响应能够重叠,多个请求和响应能够同时进行. 更加多的请求头和响应头(好比HTTP1.0没有host的字段). 总之在HTTP/1.0中,大多实现为每一个请求/响应交换使用新的链接。在HTTP/1.1中,一个链接可用于一次或屡次请求/响应交换,尽管链接可能因为各类缘由被关闭。
- persistent connection(持久链接) HTTP/1.0中,每对请求/ 响应都使用一个新的链接。 HTTP/1.1则支持持久链接(默认)。
- Host域 HTTP/1.1在请求消息头多一个Host域;HTTP/1.0 则没有这个域,创建TCP链接的时候已经指定了IP地址,并且默认一个IP地址只对应一个主机名,IP地址上只有一个host。
- 带宽优化 HTTP/1.1中在请求消息中引入了range头域,它容许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象 的偏移值和长度。若是服务器相应地返回了对象所请求范围的内容,则响应码为206(Partial Content),它能够防止Cache将响应误觉得是完整的一个对象。请求消息中若是包含比较大的实体内容,但不肯定服务器是否可以接收该请求(如是否有权限),此时若贸然发出带实体的请求,若是被拒绝也会浪费带宽。 HTTP/1.1加入了一个新的状态码100(Continue)。客户端事先发送一个只带头域的请求,若是服务器由于权限拒绝了请求,就回送响应码 401(Unauthorized);若是服务器接收此请求就回送响应码100,客户端就能够继续发送带实体的完整请求了。注意,HTTP/1.0的客户 端不支持100响应码。 节省带宽资源的一个很是有效的作法就是压缩要传送的数据。Content-Encoding是对消息进行端到端(end-to-end)的编码,它多是 资源在服务器上保存的固有格式(如jpeg图片格式);在请求消息中加入Accept-Encoding头域,它能够告诉服务器客户端可以解码的编码方 式。而Transfer-Encoding是逐段式(hop-by-hop)的编码,如Chunked编码。在请求消息中加入TE头 域用来告诉服务器可以接收的transfer-coding方式。
- 请求方法和状态码 HTTP1.1增长了OPTIONS, PUT, DELETE, TRACE, CONNECT这些Request方法 HTTP/1.0中只定义了16个状态响应码,对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域,增长对错误或警告信息的描述。 在HTTP/1.1中新增了24个状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
- 内容协商 为 了知足互联网使用不一样母语和字符集的用户,一些网络资源有不一样的语言版本(如中文版、英文版)。HTTP/1.0定义了内容协商 (content negotiation)的概念,也就是说客户端能够告诉服务器本身能够接收以何种语言(或字符集)表示的资源。例如若是服务器不能明确 客户端须要何种类型的资源,会返回300(Multiple Choices),并包含一个列表,用来声明该资源的不一样可用版本,而后客户端在请求消息中包含Accept-Language和Accept- Charset头域指定须要的版本。
- 状态码 100~199:信息状态码,表示成功接收请求,要求客户端继续提交下一次请求才能完成整个处理过程 100(continue)继续发送 200~299:成功状态码,表示成功接收请求并已完成整个处理过程,经常使用200(OK)成功接收 300~399:重定向状态码,例如,请求的资源已经移动一个新地址,经常使用30二、307和304 400~499:客户端的请求有错误,经常使用404(Not Found),403(Fobidden) 500~599:服务器端出现错误,经常使用 500
- 一个WEB站点天天可能要接收到上百万的用户请求,为了提升系统的效率,HTTP 1.0规定浏览器与服务器只保持短暂的链接,浏览器的每次请求都须要与服务器创建一个TCP链接,服务器完成请求处理后当即断开TCP链接,服务器不跟踪每一个客户也不记录过去的请求。
- 这也形成了一些性能上的缺陷,例如,一个包含有许多图像的网页文件中并无包含真正的图像数据内容,而只是指明了这些图像的URL地址,当WEB浏览器访问这个网页文件时,浏览器首先要发出针对该网页文件的请求,当浏览器解析WEB服务器返回的该网页文档中的HTML内容时,发现其中的img图像标签后,浏览器将根据img标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。
- 显然,访问一个包含有许多图像的网页文件的整个过程包含了屡次请求和响应,每次请求和响应都须要创建一个单独的链接,每次链接只是传输一个文档和图像,上一次和下一次请求彻底分离。即便图像文件都很小,可是客户端和服务器端每次创建和关闭链接倒是一个相对比较费时的过程,而且会严重影响客户机和服务器的性能。当一个网页文件中包含Applet,JavaScript文件,CSS文件等内容时,也会出现相似上述的状况。
- 为了克服HTTP 1.0的这个缺陷,HTTP 1.1支持持久链接,在一个TCP链接上能够传送多个HTTP请求和响应,减小了创建和关闭链接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答能够在一个链接中传输,但每一个单独的网页文件的请求和应答仍然须要使用各自的链接。HTTP 1.1还容许客户端不用等待上一次请求结果返回,就能够发出下一次请求,但服务器端必须按照接收到客户端请求的前后顺序依次回送响应结果,以保证客户端可以区分出每次请求的响应内容,这样也显著地减小了整个下载过程所须要的时间。基于HTTP 1.1协议的客户机与服务器的信息交换过程。
- 可见HTTP 1.1在继承了HTTP 1.0优势的基础上,也克服了HTTP 1.0的性能问题。不只如此,HTTP 1.1还经过增长更多的请求头和响应头来改进和扩充HTTP 1.0的功能。例如,因为HTTP 1.0不支持Host请求头字段,WEB浏览器没法使用主机头名来明确表示要访问服务器上的哪一个WEB站点,这样就没法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增长Host请求头字段后,WEB浏览器可使用主机头名来明确表示要访问服务器上的哪一个WEB站点,这才实现了在一台WEB服务器上能够在同一个IP地址和端口号上使用不一样的主机名来建立多个虚拟WEB站点。HTTP 1.1的持续链接,也须要增长新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持链接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭链接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
- HTTP请求报文组成:请求行+请求头+请求体
![]()
- 请求行(HTTP请求报文的第一行) 请求行由方法字段、URL字段和HTTP协议版本字段。其中,方法字段严格区分大小写,当前HTTP协议中的方法都是大写,方法字段以下介绍以下:
- 方法字段 ①GET:请求获取Request-URI(URI:通用资源标识符,URL是其子集,URI注重的是标识,而URL强调的是位置,能够将URL当作原始的URI),所标识的资源 ②POST:在Request-URI所标识的资源后附加新的数据;支持HTML表单提交,表单中有用户添入的数据,这些数据会发送到服务器端,由服务器存储至某位置(例如发送处理程序) ③HEAD:请求Request-URI所标识的资源响应消息报头,HEAD方法能够在响应时不返回消息体。 ④PUT:与GET相反,请求服务器存储一个资源,并用Request-URI作为其标识;例如发布系统。 ⑤DELETE:请求删除URL指向的资源 ⑥OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项 ⑦TRACE:跟踪请求要通过的防火墙、代理或网关等,主要用于测试或诊断 ⑧CONNECT保留未来使用
- URL 一个完整的包括类型、主机名和可选路径名的统一资源引用名,如:www.example.com/path/to/fil…
- 请求头部:位于请求行的下面 请求报文中常见的标头有: Connetion标头(链接管理)、Host标头(指定请求资源的主机)、Range标头(请求实体的字节范围)、User-Agent标头(包含发出请求的用户信息)、Accept标头(首选的媒体类型)、Accept-Language(首选的天然语言)
- HTTP首部: 6.1 通用首部:请求和响应均可以使用的; Connection:定义C/S之间关于请求/响应的有关选项 对于http/1.0, Connection: keep-alive Via: 显示了报文通过的中间节点 Cache-Control: 缓存指示 6.2 实体首部:用于指定实体属性 实体主体用于POST方法中。用户向Web服务器提交表单数据的时候,须要使用POST方法,此时主体中包含用户添写在表单的各个属性字段的值,当Web服务器收到POST方法的HTTP请求报文后,能够从实体中取出须要的属性字段的值。 也就是说,当用户经过Web浏览器向Web服务器发送请求时,Web浏览器会根据用户的具体请求来选择不一样的HTTP请求方法,再将相应的URL和HTTP协议版本及相关的标头填入头部行中,如果POST方法,还会将相关的表单数据填入实体主体中,产生一个HTTP请求报文,而后将这个报文发送给Web服务器。
请求报文分析:
![]()
常见请求头属性: Location: 资源的新位置 Allow: 容许对此资源使用的请求方法 一、内容首部: Content-Encoding:支持的编码 Content-Language:支持的天然语言 Content-Length:文本长度 Content-Location:资源所在位置 Content-Range:在整个资源中此实体表示的字节范围 Content-Type:主体的对象类型 二、缓存首部: ETag: 实体标签 Expires: 过时期限 Last-Modified: 上一次的修改时间 请求首部: Host: 请求的主机名和端口号,虚拟主机环境下用于不一样的虚拟主机 Referer:指明了请求当前资源的原始资源的URL User-Agent: 用户代理,使用什么工具发出的请求 一、Accept首部:用户标明客户本身更倾向于支持的能力 Accept: 指明服务器能发送的媒体类型 Accept-Charset: 支持使用的字符集 Accept-Encoding: 支持使用的编码方式 Accept-Language: 支持使用语言 二、条件请求首部: Expect: 告诉服务器可以发送来哪些媒体类型 If-Modified-Since: 是否在指定时间以来修改过此资源 If-None-Match:若是提供的实体标记与当前文档的实体标记不符,就获取此文档 跟安全相关的请求首部: Authorization: 客户端提交给服务端的认证数据,如账号和密码 Cookie: 客户端发送给服务器端身份标识
请求字段 1.Accept 做用:浏览器客户端用来告诉服务端能接受什么类型的响应。 例如: Accept: text/html 表明浏览器能够接受服务器回发html文档,若是服务器没法返回text/html类型的数据,服务器应该返回一个406错误(non acceptable) 通配符 * 表明任意类型。如: Accept: / 表明浏览器能够处理全部类型
Accept-Encoding 做用:浏览器客户端用来告诉服务器能接受什么编码格式,包括字符编码、压缩方式等 例如:Accept-Encoding:gzip, deflate
Accept-Language 做用:浏览器客户端用来告诉服务器能接受什么语言。 例如:Accept-Language:zh-CN,zh;q=0.9
Connection 做用:客户端或服务端用来告诉对方当前tcp链接的状态,默认为keep-alive,即长链接。 例如:Connection:close 在响应结束后关闭链接
Host 做用:指定要请求的资源所在的主机和端口,一般从url里获取。这个字段是必需的。 例如:咱们在地址栏输入:www.baidu.com Host:www.baidu.com
Referer 做用:浏览器客户端用来告诉服务器这个请求是从哪一个页面连接过来的,即请求来源。
User-Agent 做用:告诉服务器,客户端使用的操做系统、浏览器版本和名称 例如:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 另外,有些属性不必定会有但比较常见:
Cache-Control 做用:客户端浏览器用来判断是否须要用本地缓存。默认值为private;经常使用值有private、no-cache、max-age、must-revalidate。具体场景举例: a.打开新窗口时值为private、no-cache、must-revalidate,那么打开新窗口访问时都会从新访问服务器。而若是指定了max-age值(单位为秒),那么在此值内的时间里就不会从新访问服务器,例如: Cache-control: max-age=5(表示当访问此网页后的5秒内再次访问不会去服务器) b.在地址栏回车 值为private或must-revalidate则只有第一次访问时会访问服务器,之后就再也不访问。 值为no-cache,那么每次都会访问。 值为max-age,则在过时以前不会重复访问。 c.按后退按扭 值为private、must-revalidate、max-age,则不会重访问, 值为no-cache,则每次都重复访问 d.按刷新按扭 不管为什么值,都会重复访问 2.Cookie 做用:客户端浏览器用来存储一些用户信息以便让服务器辨别用户身份的(大多数须要登陆的网站上面会比较常见),好比用户名和密码,sessionId等。
If-Modify-Since 做用:把浏览器端缓存页面的最后修改时间(精确到秒)发送到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。若是时间一致,那么返回304 ,客户端就直接使用本地缓存文件。若是时间不一致,就会返回200和新的文件内容以及新的修改时间(Last-Modify)。客户端接到以后,会丢弃旧文件,把新文件缓存起来,并显示在浏览器中。 例如:Wed, 30 May 2018 08:32:42 GMT
If-None-Match 做用:If-None-Match和ETag一块儿工做,工做原理是在HTTP Response中添加ETag信息。 当用户再次请求该资源时,将在HTTP Request 中加入If-None-Match信息(ETag的值)。若是服务器验证资源的ETag没有改变(该资源没有更新),将返回一个304状态告诉客户端使用本地缓存文件。不然将返回200状态和新的资源和Etag. 使用这样的机制将提升网站的性能。 例如: If-None-Match: W/"3119-1437038474000" 注意:If-Modify-Since和If-None-Match均可以给服务器用来判断所请求的文件距离上次访问之间是否被修改过,不过If-Modify-Since只能精确到秒,而If-None-Match只要文件修改过就会变化。 Etag的使用场景: 1.有些文件须要频繁更新,可是文件内容并无变化。 2.同一文件存储在多台web服务器中,用户请求在多台之间轮询。
- HTTP响应报文一样也分为三部分,有状态行、首部行、实体
![]()
- 状态行:HTTP响应报文的第一行 状态行包括三个字段:协议版本、状态码与缘由短语。
- 状态码: 1xx: 这一类型的状态码,表明请求已被接受,须要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。 2xx: 这一类型的状态码,表明请求已成功被服务器接收、理解、并接受。 3xx: 这类状态码表明须要客户端采起进一步的操做才能完成请求。一般,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的Location域中指明。 4xx: 这类的状态码表明客户端类的错误 5xx: 服务器类的错误
- 常见状态码:
![]()
- 响应首部
![]()
- 响应字段 响应首部(首部行):位于响应报文状态行以后 Date标头:消息产生的时间 Age标头:(从最初建立开始)响应持续时间 Server标头: 向客户端标明服务器程序名称和版本 ETage标头:不透明验证者 Location标头:URL备用的位置 Content-Length标头:实体的长度 Content-Tyep标头:实体的媒体类型 协商首部: Accept-Ranges: 对当前资源来说,服务器所可以接受的范围类型 Vary: 首部列表,服务器会根据列表中的内容挑选出最适合的版本发送给客户端 跟安全相关的响应首部: Set-Cookie: 服务器端在某客户端第一次请求时发给令牌 WWW-Authentication: 质询,即要求客户提供账号和密码
- 实体: 位于首部行以后 实体包含了Web客户端请求的对象。Content-Length标头及Content-Type标头用于计算实体的位置、数据类型和数据长度。当Web服务器接收到Web客户端的请求报文后,对HTTP请求报文进行解析,并将Web客户端的请求的对象取出打包,经过HTTP响应报文将数据传回给Web客户端,若是出现错误则返回包含对应错误的错误代码和错误缘由的HTTP响应报文。
HTTPS实际就是HTTP + SSL,就是在HTTP协议的基础上增长了SSL安全加密传输。 《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种经过计算机网络进行安全通讯的传输协议,经由HTTP进行通讯,利用SSL/TLS创建全信道,加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性。
TLS是传输层加密协议,前身是SSL协议,由网景公司1995年发布,有时候二者不区分。
- 内容加密:采用混合加密技术,中间者没法直接查看明文内容
- 验证身份:经过证书认证客户端访问的是本身的服务器
- 保护数据完整性:防止传输的内容被中间人冒充或者篡改
咱们能够对比HTTP抓包分析
HTTP抓包以下:
![]()
HTTPS抓包:
经过抓包能够看到HTTPS中数据不是明文传输。HTTPS主要经过RSA混合加密,使用RSA加密客户端产生的随机秘钥,服务器端获得客户端的秘钥,双方就可使用这个随机秘钥进行对称加密传输。 ![]()
混合加密:结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密,而后使用非对称加密的公钥再对秘钥进行加密,因此网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥,所以即便被黑客截取,因为没有私钥,没法获取到加密明文的秘钥,便没法获取到明文数据。
数字摘要:经过单向hash函数对原文进行哈希,将需加密的明文“摘要”成一串固定长度(如128bit)的密文,不一样的明文摘要成的密文其结果老是不相同,一样的明文其摘要一定一致,而且即便知道了摘要也不能反推出明文。
数字签名技术:数字签名创建在公钥加密体制基础上,是公钥加密技术的另外一类应用。它把公钥加密技术和数字摘要结合起来,造成了实用的数字签名技术。
经过加密后能够作到: 收方可以证明发送方的真实身份; 发送方过后不可否认所发送过的报文; 收方或非法者不能伪造、篡改报文
- https协议须要到CA申请证书,通常免费证书较少,于是须要必定费用。(原来网易官网是http,而网易邮箱是https。)
- http是超文本传输协议,信息是明文传输,https则是具备安全性的ssl加密传输协议。
- http和https使用的是彻底不一样的链接方式,用的端口也不同,前者是80,后者是443。
- http的链接很简单,是无状态的。Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无链接的意思是指通讯双方都不长久的维持对方的任何信息。)
- 使用Https协议可认证用户和服务器,确保数据发送到正确的客户机和服务器。
- Https协议是由SSL+Http协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程当中不被窃取、修改,确保数据的完整性。
- Https是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增长了中间人攻击的成本。
- Https协议握手阶段比较费时,会使页面的加载时间延长近。
- Https链接缓存不如Http高效,会增长数据开销,甚至已有的安全措施也会所以而受到影响;
- SSL证书一般须要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗。
- Https协议的加密范围也比较有限。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家能够控制CA根证书的状况下,中间人攻击同样可行。
以下图:
过程详解: ![]()
- ①客户端的浏览器向服务器发送请求,并传送客户端SSL 协议的版本号,加密算法的种类,产生的随机数,以及其余服务器和客户端之间通信所须要的各类信息。
- ②服务器向客户端传送SSL 协议的版本号,加密算法的种类,随机数以及其余相关信息,同时服务器还将向客户端传送本身的证书。
- ③客户端利用服务器传过来的信息验证服务器的合法性,服务器的合法性包括:证书是否过时,发行服务器证书的CA 是否可靠,发行者证书的公钥可否正确解开服务器证书的“发行者的数字签名”,服务器证书上的域名是否和服务器的实际域名相匹配。若是合法性验证没有经过,通信将断开;若是合法性验证经过,将继续进行第四步。
- ④用户端随机产生一个用于通信的“对称密码”,而后用服务器的公钥(服务器的公钥从步骤②中的服务器的证书中得到)对其加密,而后将加密后的“预主密码”传给服务器。
- ⑤若是服务器要求客户的身份认证(在握手过程当中为可选),用户能够创建一个随机数而后对其进行数据签名,将这个含有签名的随机数和客户本身的证书以及加密过的“预主密码”一块儿传给服务器。
- ⑥若是服务器要求客户的身份认证,服务器必须检验客户证书和签名随机数的合法性,具体的合法性验证过程包括:客户的证书使用日期是否有效,为客户提供证书的CA 是否可靠,发行CA 的公钥可否正确解开客户证书的发行CA 的数字签名,检查客户的证书是否在证书废止列表(CRL)中。检验若是没有经过,通信马上中断;若是验证经过,服务器将用本身的私钥解开加密的“预主密码”,而后执行一系列步骤来产生主通信密码(客户端也将经过一样的方法产生相同的主通信密码)。
- ⑦服务器和客户端用相同的主密码即“通话密码”,一个对称密钥用于SSL 协议的安全数据通信的加解密通信。同时在SSL 通信过程当中还要完成数据通信的完整性,防止数据通信中的任何变化。
- ⑧客户端向服务器端发出信息,指明后面的数据通信将使用的步骤. ⑦中的主密码为对称密钥,同时通知服务器客户端的握手过程结束。
- ⑨服务器向客户端发出信息,指明后面的数据通信将使用的步骤⑦中的主密码为对称密钥,同时通知客户端服务器端的握手过程结束。
- ⑩SSL 的握手部分结束,SSL 安全通道的数据通信开始,客户和服务器开始使用相同的对称密钥进行数据通信,同时进行通信完整性的检验。
一、https协议须要到ca申请证书,通常免费证书较少,于是须要必定费用。 二、http是超文本传输协议,信息是明文传输,https则是具备安全性的ssl加密传输协议。 三、http和https使用的是彻底不一样的链接方式,用的端口也不同,前者是80,后者是443。 四、http的链接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
链接过程:
- client向server发送请求https://baidu.com,而后链接到server的443端口,发送的信息主要是随机值1和客户端支持的加密算法。
- server接收到信息以后给予client响应握手信息,包括随机值2和匹配好的协商加密算法,这个加密算法必定是client发送给server加密算法的子集。
- 随即server给client发送第二个响应报文是数字证书。服务端必需要有一套数字证书,能够本身制做,也能够向组织申请。区别就是本身颁发的证书须要客户端验证经过,才能够继续访问,而使用受信任的公司申请的证书则不会弹出提示页面,这套证书其实就是一对公钥和私钥。传送证书,这个证书其实就是公钥,只是包含了不少信息,如证书的颁发机构,过时时间、服务端的公钥,第三方证书认证机构(CA)的签名,服务端的域名信息等内容。
- 客户端解析证书,这部分工做是由客户端的TLS来完成的,首先会验证公钥是否有效,好比颁发机构,过时时间等等,若是发现异常,则会弹出一个警告框,提示证书存在问题。若是证书没有问题,那么就生成一个随即值(预主秘钥)。
- 客户端认证证书经过以后,接下来是经过随机值一、随机值2和预主秘钥组装会话秘钥。而后经过证书的公钥加密会话秘钥。
- 传送加密信息,这部分传送的是用证书加密后的会话秘钥,目的就是让服务端使用秘钥解密获得随机值一、随机值2和预主秘钥。
- 服务端解密获得随机值一、随机值2和预主秘钥,而后组装会话秘钥,跟客户端会话秘钥相同。
- 客户端经过会话秘钥加密一条消息发送给服务端,主要验证服务端是否正常接受客户端加密的消息。
- 一样服务端也会经过会话秘钥加密一条消息回传给客户端,若是客户端可以正常接受的话代表SSL层链接创建完成了。
怎么保证保证服务器给客户端下发的公钥是真正的公钥,而不是中间人伪造的公钥呢?
证书如何安全传输,被掉包了怎么办?
包括了加密后服务器的公钥、权威机构的信息、服务器域名,还有通过CA私钥签名以后的证书内容(通过先经过Hash函数计算获得证书数字摘要,而后用权威机构私钥加密数字摘要获得数字签名),签名计算方法以及证书对应的域名。
- 当客户端收到这个证书以后,使用本地配置的权威机构的公钥对证书进行解密获得服务端的公钥和证书的数字签名,数字签名通过CA公钥解密获得证书信息摘要。
- 而后证书签名的方法计算一下当前证书的信息摘要,与收到的信息摘要做对比,若是同样,表示证书必定是服务器下发的,没有被中间人篡改过。由于中间人虽然有权威机构的公钥,可以解析证书内容并篡改,可是篡改完成以后中间人须要将证书从新加密,可是中间人没有权威机构的私钥,没法加密,强行加密只会致使客户端没法解密,若是中间人强行乱修改证书,就会致使证书内容和证书签名不匹配。
(假装服务端同样的配置)显然这个是不行的,由于当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证实你是服务端域名的拥有者,而第三方攻击者是没法提供这些信息因此他就是没法骗CA他拥有属于服务端的域名
- 中间人攻击(MITM攻击)是指,黑客拦截并篡改网络中的通讯数据。又分为被动MITM和主动MITM,被动MITM只窃取通讯数据而不修改,而主动MITM不但能窃取数据,还会篡改通讯数据。最多见的中间人攻击经常发生在公共wifi或者公共路由上。
- HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么做用 SSL证书的信用链体系并不安全,特别是在某些国家能够控制CA根证书的状况下,中间人攻击同样可行
- SSL证书须要购买申请,功能越强大的证书费用越高
- SSL证书一般须要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗(SSL有扩展能够部分解决这个问题,可是比较麻烦,并且要求浏览器、操做系统支持,Windows XP就不支持这个扩展,考虑到XP的装机量,这个特性几乎没用)。
- 根据ACM CoNEXT数据显示,使用HTTPS协议会使页面的加载时间延长近50%,增长10%到20%的耗电。
- HTTPS链接缓存不如HTTP高效,流量成本高。
- HTTPS链接服务器端资源占用高不少,支持访客多的网站须要投入更大的成本。
- HTTPS协议握手阶段比较费时,对网站的响应速度有影响,影响用户体验。比较好的方式是采用分而治之,相似12306网站的主页使用HTTP协议,有关于用户信息等方面使用HTTPS。
- 这个主要是专业机构认证的CA证书费用很高,通常须要5千美金一年。不少公司承受不了这样的费用
- CA认证证书,客户端不须要作任何处理就能够访问,根HTTP同样使用,可是自签名证书须要本身实现安全认证后,信任后才能使用。
- 苹果自2017年后要求全部HTTP通信必须走HTTPS方式,不然不予审核经过。
- 对于嵌入式设备和App的通信使用自签名证书比较灵活一点。
- 自签证书相对申请CA证书,流程更简单
- 自签证书一样能够对数据进行加密
- 自签证书的有效期能够设置很长,免去续签的麻烦
- 自签证书更方便测试,好比说你想生成多少个不一样服务器ip的均可以
1)认证用户和服务器,确保数据发送到正确的客户机和服务器 2)加密数据以防止数据中途被窃取 3)维护数据的完整性,确保数据在传输过程当中不被改变
- SSL证书是数字证书的一种,相似于驾驶证、护照和营业执照的电子副本。
- SSL证书的两大做用:数据加密和身份认证
- SSL 证书遵照 SSL协议,经过在客户端浏览器和Web服务器之间创建一条SSL安全通道
- 一个有效、可信的 SSL 数字证书包括一个公共密钥和一个私用密钥。公共密钥用于加密信息,私用密钥用于解译加密的信息。所以,浏览器指向一个安全域时,SSL 将同步确认服务器和客户端,并建立一种加密方式和一个惟一的会话密钥。它们能够启动一个保证消息的隐私性和完整性的安全会话。