对https的理解

最近把APP的协议改成了https，又看了些资料，比以前又加深了一点理解，本文总结一下

https解决的问题

http主要有3方面的安全问题：

1、明文传输

2、无法认证server和client的身份

3、无法保证数据完整性（会被篡改）

针对这3个问题，https都提供了协议层面的解决方案：

https使用密钥对传输的内容进行加密和解密，从而避免了报文在网络里明文传输

同时https用证书来证明通信双方的身份。比如说，用户在浏览器里输入https://www.example.com，但是如何能证明发送响应的站点真的是www.example.com呢？无论是篡改hosts，或是DNS劫持，该域名都可能指向一个钓鱼网站。但是有了证书，就可以避免这个情况。攻击者即使劫持了用户的DNS，但是它并没有真正的证书和私钥，所以浏览器也会给出警告；对于双向认证也是一样，server端通过校验客户端证书，也可以做到只允许认证用户访问

最后一个数据完整性的问题，server会给一个唯一的token，client的请求加上token做了摘要计算以后，发送到server。如果报文被中途篡改，那么就无法反向算出正确的token，就可以识别出此次请求是被篡改过的

RSA解决的问题

前面说过，https用密钥来加密传输的报文。但是原本的对称加密算法，在密钥传输上有安全问题。因为对称加密算法，需要server先把密钥给到客户端，然后才能建立https通道，但是密钥本身的发送却是不安全的，就成了一个先有鸡还是先有蛋的矛盾

所以作为改进，现在主要都是使用非对称加密，最常见的就是RSA算法。server可以把公钥公开给客户端，但是私钥只有自己有一份，因此避免了在https通道建立之前，发送密钥的安全问题

客户端认证

http提供了basic和digest认证方式，https还提供了client certificate方式。但是都不太实用。实际上一般都需要在应用层面做客户端认证。我想一个主要的原因，是需要对用户做区分。比如A和B都有客户端证书，但是server还是需要区分此次请求来自A用户还是B用户，光靠client certificate很难做到这点。所以实践中，即使是采用https通信的网站，一般还是需要借助应用层面的认证方式

对于java平台，最常见的就是基于cookie或者URL rewrite的session方式

https对资源本身无影响

https本质是在http和tcp之间增加了SSL（TLS）层，应用层的协议还是http。站点提供的静态资源，或者web服务，本身是不受任何影响的。简单来说，比如网站提供了icon.png图片，或者/svc/userList服务，那么用2个URL访问都是没问题的：

http://www.example.com/icon.png

https://www.example.com/icon.png

当然前提是http服务器需要打开80和443端口。如果用户使用http协议访问，就用http协议通信；否则就使用https。至于资源本身，并不受协议切换的影响。以前我不懂，还说过“这是https服务，用http协议不能访问”这样的蠢话