现在的互联网金融市场火爆异常，人人想分一杯羹，黑帽子对互联网金融公司也非常热衷，公司的服务器近段时间遭遇了几次恶意攻击，虽然没造成非常严重的影响，但公司管理层开始将网络安全列为了各大技术会议的重中之重，以前一直没太注意安全方面知识的积累，此时才感觉不够用，所以近段时间也一直在亡羊补牢，在此分享下有关HTTPS基础原理的一些收获。

首先介绍一下安全套接字层 (SSL)（现在技术上称为传输层安全协议 (TLS)）是一个通用构建块，用于在客户端与服务器之间进行加密通信。应用很可能以错误的方式使用 SSL，从而导致恶意实体能够拦截网络上的应用数据。HTTPS其实是有两部分组成：HTTP+ SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

下图是一张经典的客户端及服务器使用HTTPS协议交互的图片

上图描述了客户端及服务端交互过程中的加解密以及验证过程。

下面对上图的流程逐步进行解析

    1. 客户端发起HTTPS请求

    客户端发起了一个https请求或者浏览器里输入一个https网址，然后连接到server的443端口。

    2. 服务端的配置

    采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向CA机构申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面或者报SSLHandshakeException。这套证书其实就是一对公钥和私钥。

    3. 传送证书

    这个证书其实就是公钥，只是包含了很多信息，如

• 证书是否过期

• 发型服务器证书的CA是否可靠

• 返回的公钥是否能正确解开返回证书中的数字签名

• 服务器证书上的域名是否和服务器的实际域名相匹配

等等。

    4. 客户端解析证书

    这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。

    5. 传送加密信息

    这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

    6. 服务段解密信息

    服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

    7. 传输加密后的信息

    这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

    8. 客户端解密信息

    客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

当Android客户端访问https网站，默认情况下，受证书信任限制，无法访问，可以有两种解决方法来实现：

1、将要访问的https网站的ca证书添加到客户端信任证书列表中，此种方式为谷歌推荐，安全性高。

2、将客户端设置为信任所有证书，也就是说不验证服务器证书，此种方式实现简单，但是安全性低，不推荐使用。

具体的实现代码网上有很多，可以参见http://blog.csdn.net/whu_zhangmin/article/details/45868057

第二种方案是开发者经常误用的，这种方法虽然可以规避SSLHandshakeException同时客户端跟服务器的交互的消息也是经过加密的，但是仍然是非常危险的，常见的中间人攻击对这种做法可以造成致命性的打击。如果您这样做还不如不加密通信，因为任何人都可以在公共 WLAN 热点下，使用伪装成您的服务器的代理发送您的用户流量，通过 DNS 欺骗攻击您的用户。然后，攻击者可以记录密码和其他个人数据。此方法之所以有效是因为攻击者可以生成一个证书，且没有可以切实验证证书是否来自值得信任的来源的 TrustManager，从而使您的应用可与任何人通信。

上面的图片介绍的是HTTPS的单向认证，client从server处拿到server的证书，通过公司的CA去验证该证书，以确认server是真实的，这种认证已经较为安全，如果对安全有更高的需求，可以采取双向认证的方式，银行的业务一般会采取双向认证这种方式，撒胡姑娘想认证的内容不再展开，如果有兴趣可以继续阅读http://blog.csdn.net/duanbokan/article/details/50847612