HTTPS协议原理透析

1、HTTPS本身并非协议，而是标准的HTTP协议架在SSL/TLS协议之上的一种结构。（一种不太合适的说法可以认为是两种协议的叠加）。HTTP是工作在OSI7层模型的最上层，就是第7层：Application Layer。而SSL/TLS是工作在第4层：Transport Layer。两层之间还是隔了Presentation Layer（6层）和Session Layer（5层）两层的。

2、由于基于TCP/IP协议的通讯需要，HTTPS也还是必须暴露IP和Port出来，即这部分不在加密范畴之内。所以第三方还是可以通过截取网络包数据等手段，知道用户正在和哪个site通讯，当然，除了www.domain.com:port这部分数据之外，context后面的信息是加密的。

3、加密链接建立的核心基础是SSL/TLS的握手过程，这个过程要比TCP协议建立链接的3次握手过程复杂一些。参考了wikipedia中描述的过程http://en.wikipedia.org/wiki/Transport_Layer_Security，自己大概整理了一下这个握手过程，大概是下面这个样子的：

 

4、从上面的这个过程可以总结一下这个安全链接建立的过程：

 

• client和server通讯为了保证安全性，所以通讯的消息得加密，即网络上密文传输。为了方便对方获得真实的消息，这个加密得使用对称加密算法。于是，这个加密的安全性就取决于密钥本身的强度以及所选用的对称加密算法了。
• 可是到底用什么密钥和对称加密算法呢？client和server互不认识，怎么会有默契上来就知道这两个东东都用啥？于是这事儿得client和server谈判！
  •  client给server发送了个ClientHello，里面包括：client能支持的TLS的最高版本、一个随机数A、client所能支持的加密算法集合、client所能支持的压缩算法集合。
  • server收到个ClientHello之后，拿出自己所能支持的TLS的最高版本跟client发过来的最高版本比较一下，这两个版本取个Max，这里标记为：max_TLS_version。server自己再生成个随机数B，从client传过来的加密算法集合中挑一个具体的加密算法M（注意，这里的M其实也是一个集合，包括：非对称加密算法用于加密上图的pre-master secret，比如RSA算法、对称加密算法用于数据传输时双方使用的加密自己的内容解密对方内容的依据、MAC算法用于校验信息是否被篡改、伪随机算法用于生成最终通讯时对称加密算法所需要的密钥master secret），从压缩算法集合中挑一个具体的压缩算法N。然后发送一个ServerHello作为回应给client，这个ServerHello就包括上面提到的max_TLS_version/B/M/N。
  • 注意，这时client和server双方之间的信息基本比较对称了。因为双方已经协商好整个握手过程中所有可能需要涉及到的算法。
  • server发送自己经过第三方认证的证书给client，告诉他：哥是有证经营的，你可以拿我的证去随便调查。
  • client拿着server发过来的证书跑去权威的有关部门验证去了。。。（这两步涉及到的CA证书认证内容又很大，这里不展开描述，先将主要精力放在TLS握手上）
  • 假设上面的证书验证通过了，这就意味着client相信server发过来的证书了，也就意味着client同意用server发过来的public key开始通讯了。注意，非对称加密的过程在这里开始了。client生成了一个pre-master secret（通常也是一个随机数）P，使用server提供的public key加密P之后生成P'， 将P'发给了server。
  • server收到P'后，用自己的private key解密还原出了P。注意这个P和之前A的最大不同是加密传输过来的哦。而且理论上在server没有泄露自己private key的情况下， 只有server能够从P'还原出P。So，此时，client和server双方已经具备了生成双方后面通讯时对称加密需要使用的master secret的条件：双方都有的一个确定的伪随机函数、3个彼此都知道的随机数A、B和P。
  • 于是，双方在自己一方，通过共同的伪随机数和共同的素材，生成出来了master secret。到这里，双方谈判的过程基本上可以结束了。因为谈判的初衷已经完全符合了。回想一下，整个过程不就是为了在公网上这个非安全的环境中让彼此都清楚使用啥对称加密算法以及使用什么密钥吗？等等，这个握手过程为了保证可用性，还拿出来先测试一下，是否真的行得通才行啊。于是还有下面的两步。
  • client用双方同意的MAC（message authentication code）算法，比如MD5，加密一段明文Q（这个明文是啥应该都没关系，因为都会发给server的）生成了MAC。然后用双方同意的对称加密算法（比如AES）加密了Q和MAC之后，生成了一段Finished Message发给了server。（这里，根据TLS record protocol，这个Finished Message其实是个具体的TLS record，他携带的Content type为20，这相当于告诉server：I am ready to begin the normal communication.）
  • server收到这条TLS record之后，就会尝试先解密密文（Decryption），再用约定的MAC算法验证内容是否被篡改（Verification）。这时，如果这两个任何一项工作失败了，就前功尽弃了。。。这里假设都成功了，于是server做了上一步client同样的事情：生成一份Content type为20的Finished Message，发给client。至此，整个握手过程正式结束。。。下面的通讯就是双方直接使用对称加密算法直接加解密message的过程啦，当然每次交互的过程中，还会包括上面描述的MAC验证的过程。