什么是https？？
wikipedia的解释是：
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性
我们再来看看网络安全的几个基本问题。可以粗略的分成四个相互交织的领域：
保密
它的任务是确保信息不会被未经授权的用户访问
认证
当你在展示敏感信息或者进入电子商务交易之前你必须要确定自己在和谁通话
不可否认
契约的任何一方不能否认自己曾经签过名的特性
完整性控制
用来确定你收到的信息是真实的而不是被恶意攻击者在传输图中篡改过的伪造信息
所以，理论上说将这四个问题解决就可以形成一个网络安全的实现。而https是一个典型的网络安全问题解决方案，前面定义中涉及到的SSL/TLS加密、身份认证、完整性等也都和这几个问题呼应。下面介绍基本的密码学原理。
有哪些密码学原理？？
保密——加密算法
密码学众所周知有两种典型的加密技术：
对称密钥加密技术
发送端和接收端要共享相同的密钥k才能进行通信，发送端接收端用共享的密钥来加密报文和恢复报文，流行的对称密钥算法包括：DES、Triple-DES、AES，RC2和RC4
算法的细节我们不用考虑，不过很显然，对称加密的弱点就在于密钥的管理。
对称密钥加密技术的缺点之一就是发送者和接收者在互相对话之前一定要有一个共享的保密密钥，如果有N个节点每个节点都要和其他所有N-1个节点进行安全对话，总共大概会有N的平方个保密密钥，这将是一个管理噩梦。
同时，加密安全性依赖于密钥本身的安全性，共享密钥的环节密钥一旦泄露再健壮的算法也会被瞬间攻破。
公开密钥加密技术
针对对称密钥的缺点，公开密钥加密技术应运而生：
没有对每对主机使用单独的加密/解密密钥，而是使用了两个（非对称）密钥：一个用来对主机报文编码，另一个用来对主机报文解码。编码密钥是众所周知的（这也是公开密钥加密这个名字的由来），但只有主机才知道私有的解密密钥，这样每个人都能找到特定主机的公开密钥编码，而只有接收端才能对发送给它的报文进行解码
即——<u>公钥加密，私钥解密</u>。A和B每个主机有自己的公钥，也有自己的私钥，B想要给主机A发送报文，B就用主机A的公钥进行加密，然后传递给A，A再利用自己的私钥进行解密就可以了。反之亦然。对于一个接受者来说，任何人都可以用我分发出去的公钥加密，但是加密之后只有我才能解密。这个方法解决了共享密钥产生的密钥安全性问题。
典型的非对称加密算法是RSA。
同样我们不需要知道算法的细节，但是要了解的是，非对称加密的缺点就是速度很慢，如果数据都使用非对称加密进行编码传输效率会非常低。
上述的SSL/TLS本身并不是加密算法，他们是一组安全协议，构成网络协议栈当中的一个安全层。这个安全层提供一种机制让收发双方进行参数协商，认证，保密通信，数据的完整性保护等等，稍后会详细说明。
完整性——数据校验和
加密提供了对明文保密的机制，不过它并不能保证发送内容不被篡改。比如A向B发送加密数据，攻击者C虽然不能解密A发送的密文信息，但是可以自己随意用B的公钥加密一段密文或者在链路上窃取一段密文替换部分真实的A密文，从而破坏信息的正确性和完整性。那么如何做到被加密之后还不能被篡改呢？
对于保证数据完整性，密码学给出的典型方案就是为明文计算一个校验和或者叫摘要的信息（又叫指纹信息），目前比较流行摘要有MD5，SHA1等等，它们能生成一个数据完整性的校验和（MAC），和密文一并发送出去。接收方拿到密文解密之后，用同样的算法计算校验和传过来的校验和比对，即可知道数据是否被篡改。加密内容与校验和是互校验的，在加密算法安全的条件下，整个密文与校验和是配套的，二者任何一处被修改都能被检验出来。
可是紧接着问题又来了，如果报文并非期待的对象发出，而是攻击者擅自发出的加密报文，整个报文都是假的呢？
认证与不可否认——数字签名
签名的原理我们都理解，它用来证明文件是出自签名者本人，对于文件的接受人来说它具有认证的作用（确认文件的来源），对于文件的起草者有不可否认的作用（对于文件出自他不能抵赖）。
那么在网络环境中有没有什么办法起到“签名”或者“按手印”这样的作用呢。当然有，也就是我们经常听到的一个词叫“数字签名”。
还记得刚刚讲到的公开密钥加密算法吗，比如RSA，它的加密方式是公钥加密，私钥解密。但是RSA算法也支持相反的一种工作方式，即<u>私钥加密，公钥解密</u>（私钥加密的数据，只有对应的公钥可以解开）。你可能困惑，这还加什么密啊，人人都能解密。的确是这样，所以这种工作方式不在于向对方传递加密数据，而是为了说明数据的来源，如果一段密文能够用公钥正确解密说明这个数据就是来自于私钥属主，这恰恰是数字签名的一种典型实现。
有了数字签名，之前完整性校验留下的问题是不是可以解决了？假设A需要发送一个报文，现在的报文结构是密文+校验和，如果我在此基础上将校验和用A的私钥加密（也就是添加A的签名），看看是什么效果：
对于攻击者C来说，他拿到这样一个报文，首先他并不能解密密文（假设算法与密钥安全），其次他也不能篡改这个报文的任何一部分（加密密文，签名的校验和），因为这两部分是互校验的，同时他也不能伪造整个报文，因为他不可能对校验和有正确的签名（没有正确私钥）。由此可见加密+校验和+数字签名的方案很好的解决了破解、篡改与伪造的问题。
所以数字签名也可以简单的理解成：<u>对校验和进行私钥加密</u>。
这个思路距离https实际的工作过程已经很接近了，不过之前我们一直有个问题没考虑清楚。就是到底
采用哪一类加密算法？？
如果使用对称加密算法，并且存储通讯对象的密钥，那么管理成本非常大，也很危险。如果每次通信都交换密钥，密钥泄露的风险就变得更大。但是反过来一旦安全交换了密钥，加密通信性能会比较好。同时对称加密由于密钥只关系到双方，所以约定密钥的人可以采用一个随机值，这样安全交换密钥之后，双方可以不对自己的报文签名也能验证起到认证的作用。
如果使用非对称加密算法，在密钥安全性方面相比对称加密会好很多（依赖获取的公钥的安全性），但是每次通信获取对方公钥的成本会很高，同时加密解密的性能会很差。因为本身算法性能就差，而且非对称加密的接受方每次必须通过签名确认报文的属主。于是发送方必须在发送报文时添加签名，也就是说每个报文发送方要做两次加密，接收方要做两次解密。这种性能肯定是不能忍的。
所以对于这两个矛盾又互补的方案来说，最好的办法就是将它们结合起来使用，因此，现实中https的方案：
是在两个节点之间通过便捷的公开密钥加密技术建立起安全通信，然后再用那条安全的通道产生发送临时的随机对称密钥，通过更快的对称加密技术对其余的数据进行加密
更简单一点理解，就是用<u>非对称加密传输对称加密的密钥，然后用对称加密通信</u>。
假设A发起与B的通信，首先A获取B的公钥（先用非对称加密），然后A告诉B，“自己要用AES算法进行对称加密，密钥是xxx”，这个密钥是一个随机数，然后这条报文用B的公钥加密传给B，这条报文只有B能解密所以很安全，紧接着A和B就采用AES和约定的随机密钥加密报文，愉快的通信起来……
居然阻止不了“中间人攻击”
这个方法看起来天衣无缝，首先用非对称加密解决了对称加密密钥交换的问题，对称加密解决了性能问题，还不用每个报文都添加签名认证……如果说还有什么不安全的地方，对，聪明的你一定发现了，那就是获取公钥时的安全性。
还是刚才那个完全一样的过程，只是第一步A获取B公钥时出现了问题，假设A在四处打听B的公钥是什么，这时候攻击者C跳出来说，我是B，我的公钥是kkk，A很天真的相信了C的话，用kkk加密把密钥给了C然后把跟B通信的内容都发给了C，和C愉快的通信起来……
更过分的是C可能不一定会露出马脚让A发现他是伪装者，他这边与A建立通信之后反手又冒充A与真正的B建立通信，收到A的信息之后转发给B，B回传的响应再转发给A，他就这样神不知鬼不觉的将AB之间的通信尽收眼底，时不时还能再添点油加点醋，前面研究半天的加密措施，全都被绕过了！
由此可见，公钥的安全管理非常重要，一旦拿到的是假公钥那么连简单的“中间人攻击”都抵挡不了，前面利用那么多加密认证手段都前功尽弃了。
可是，非对称加密以及后续全套加密全部工作就是建立在对所持公钥的信任基础上，我去哪拿安全的公钥呢，拿到公钥的可信度又由谁来保证呢？
数字证书——由一个可信组织签名担保公钥安全性
又是一个熟悉的名词，“数字证书”：
数字证书中包含了由某个受信任组织担保的用户或公司的相关信息。数字证书中还包含一组信息，所有这些信息都是由一个官方的“证书颁发机构”已数字方式签发的。有一些常见的内容
- 对象的名称（这个证书所描述的实体，人、服务器、组织等）
- 过期时间
- 证书发布者（由谁为证书担保）
- <u>来自证书发布者的数字签名</u>
- <u>对象的公开密钥</u>
- 对象和所用的签名算法的描述性信息
可以这么理解，<u>数字证书上面写着你要通信的服务器的公钥，同时这个证书加上了一个权威担保机构的签名</u>，证明这个公钥的真实性。
也就是说，A现在要和B服务器进行安全通信，不需要四处寻找B的公钥了，B会给A发送一个证书过来，其实就是一张名片，上面写着我是谁谁谁，地址在哪，公钥是多少，上面还盖着一个“世界超级值得信任评估委员会”的大印。
A肯定会怀疑“世界超级值得信任评估委员会”是个什么鬼？因为这个担保机构可信度不高。由此可见，无论是人还是协议都得有一个信任的衡量标准，什么“世界”，什么“大机构”都是空话。
证书与根证书
对于服务器发过来的证书，浏览器的信任标准，就在机器的本地。每台机器的操作系统当中都安装了很多的“根证书”，这些是权威机构给自己颁发的，<u>不需要其他人担保的证书</u>。它上面的内容也是有信誉的大机构（CA组织）的公钥。根证书只要安装到机器当中，浏览器（客户端）就无条件认为上面的公钥是可信的，而这些公钥的作用就是验证服务器发送过来的证书的签名。比如上述“世界超级值得信任评估委员会”的签名，如果我的机器上安装有该机构的根证书，那么我就认为这个签名是可信任的，然后就可以建立后续的安全通信了。
很多时候我们收到的证书并不只有一个，而是一组，比如一个B公司的站点给我一个证书，上面是B公司的信息，签名是一个C机构的，也就是由C机构担保（记作：<B,C>），而这组证书当中还有两个证书<C,D>和<D,E>，校验签名的时候C，D公司的签名我都不认识（本地没有二者的根证书），但是E的签名我认识并认为可信，因为我安装了E的根证书。所以这就形成了一个“担保链”：E担保D担保C担保B，出于对E的信任最终也信任了B，这组证书叫做“证书链”。没有从根证书发布机构而是从其授权机构申请的证书，都需要通过“证书链”的方式发送给接收者。
至此，https当中的关键概念都帮助大家扫盲了一遍。下面再说https的工作过程应该就很好理解了。
HTTPS工作过程
https特殊的工作过程体现在SSL/TLS层上，它建立在HTTP应用层协议之下作为一个安全服务层，因此对于HTTP本身完全是透明的。因为在处理HTTPS流量时需要额外的安全层操作（加解密、验证签名、校验等），所以tcp连接选择建立在服务器的443端口上，与http的80端口作以区分。
SSL是安全套接层（Secure Sockets Layer），由网景公司于1994年提出，随后SSL3.0由IETF进行了标准化，发布了TLS（Transport Layer Security），二者差异很小，以下用SSL代指安全层。
对于SSL来说两部分协议比较重要，一部分是“SSL握手协议”，一部分是“SSL记录协议”。
SSL握手协议：
Note：上述消息5中，发送的是一个随机的384位预设主密钥，而真正的通信对称密钥是双方用主密钥与上面的两个随机数推导出来的。
经过握手以后，双方就可以进行安全通信了，通信过程需要经过SSL记录协议来完成：
SSL记录协议：
总结
对于https来说，其实就是灵活地将密码学当中的诸多原理“拼装”形成的一个安全方案。报文加密可以解决保密问题，数据校验和可以解决完整性问题，数字签名可以解决身份认证与不可否认问题。
https握手过程 1.确认具体算法 2.服务端（用证书）发送自己的公钥 3.客户端用<u>服务端公钥</u>加密<u>对称算法密钥</u>发送给服务端 4.二者用对称密钥通信
其中，非对称加密只在握手过程中只进行了一次，其余所有传输都用对称加密。这个方案兼顾防止对称密钥泄露，同时避免了非对称加密中认证和算法本身的额外性能开销。
证书相当于告知一个公钥，但是带着一个ca组织的签名，如果客户端机器上安装了对应组织的根证书，那么这个证书上所有信息（最重要）相当于可信任，防止“中间人攻击”。
以上就是SSL的基本工作过程，本文省略了很多技术细节，强调安全传输的整体思路，希望能对大家理解https与网络安全相关知识有一些帮助。
