|
SSL的工作层面，以HTTPS为例： SSL协议使用不对称加密技术实现会话双方之间信息的安全传递。可以保证信息的保密性、完整性，并且会话双方能鉴别对方身份。下面是一个通过浏览器与Web网站建立HTTPS连接时，浏览器与Web服务器之间经过一个握手的过程来完成身份鉴定与密钥交换，从而建立安全连接的具体过程，如下：
1. 用户浏览器将其SSL版本号、加密设置参数、与Session有关的数据以及其它一些必要信息发送到服务器。
2. 服务器将其SSL版本号、加密设置参数、与Session有关的数据以及其它一些必要信息发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。
3. 客户端检查服务器证书，如果检查失败，则提示不能建立SSL连接。如果成功，则继续。
4. 客户端浏览器为本次会话生成Pre-master secret，并将其用服务器公钥加密后发送给服务器。
5. 如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。
6. 如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的Pre-master Secret，并用它通过某些算法生成本次会话的Master secret。
7. 客户端与服务器均使用此Master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时加密解密的运算速度。
8. 客户端通知服务器此后发送的消息都使用这个会话密钥进行加密。并通知服务器客户端已经完成本次SSL握手。
9. 服务器通知客户端此后发送的消息都使用这个会话密钥进行加密，并通知客户端服务器已经完成本次SSL握手。
10. 本次握手过程结束，会话已经建立。双方使用同一个会话密钥分别对发送以及接收的信息进行加、解密。
有很多实现ssl mitm（中间人攻击，Man In The Middle）攻击的工具，具体实现是这样的：
1、攻击软件通过arp或http代理截取http流量
2、当客户端服务器请求https页面时，攻击软件截获证书，并使用该证书的相关信息及自己产生的public key生成新的证书替换服务器的证书，并把新证书发给客户端。 3、客户端使用收到证书中的public对数据进行加密并传送给服务器。 4、攻击软件使用之前自己生成的private key进行解密，并使用服务器的public key 进行加密后传送到服务器。 5、攻击软件使用服务器的public key 解密服务器返回的数据，并使用自己生存的private key 对数据进行加密后传给客户端。 大概就是这样，浏览器如果遇到ssl MITM攻击会提示证书错误：
A proper web browsing client will warn the user of a certificate problems if any of the
following are not true: A. the certificate has been signed by a recognized certificate authority B. the certificate is currently valid and has not expired C. the common name on the certificate matches the DNS name of the server 其中A是关键。
在局域网中防范此类攻击，技术上首先杜绝ARP欺骗的发生，另外要教育用户在使用Https网站时注意证书错误提示。
还有就是不能让用户使用那些乱七八糟的浏览器，那些浏览器安全性不高而且可能留有后门。 这种中间人攻击理论上不可避免，除非服务器对客户端进行验证，如我们网银使用的数字证书就是用来对客户端进行验证避免受到中间人攻击。
中间人攻击，用户会收到证书无效的警告。用户如果忽略警告，那么简单的说，HTTPS等于HTTP
如果用户不忽略警告，那么HTTPS可以防止网络上的窃听。当然也存在一些类似最近发现的SSL prefix攻击的一些漏洞，在一定条件下可以达到一定程度的攻击。但是还是比HTTP好多了
ssl过程：
我们知道，https的安全性主要是由SSL证书中的公钥和私钥来保证的。浏览器与服务器经过https建立通讯的时候（不考虑SSL代理方式需要用户提交证书的情况，因为我们现在讨论的是浏览器访问网站，和SSL代理无关）会按照以下步骤保证通讯的安全性： 1、浏览器连接服务器，服务器把SSL证书的公钥发送给浏览器 2、浏览器验证此证书中的域是否和访问的域一致（比如用户访问https://mail.google.com/时，浏览器验证服务器发送过来的SSL证书的公钥中的域是否为mail.google.com或*.google.com）并没有过期 3、如果浏览器验证失败，浏览器通知用户证书有问题，让用户选择是否继续 4、如果浏览器验证成功，那么浏览器随机生成一个对称密钥并使用接收到的SSL证书的公钥进行加密并发送给服务器 5、服务器通过SSL证书的私钥对收到的信息进行解密并得到浏览器随机生成的对称密钥 6、最后服务器和浏览器都通过这个对称密钥进行通讯了（为什么不直接使用公钥和私钥进行通讯？因为非对称加密比对称加密效率低） 这个方案看似完美，却无法抵御中间人攻击，攻击者可以按以下步骤实施攻击截取https通讯中的所有数据： 1、攻击者伪造一个Gmail的SSL证书，使其中的域为mail.google.com或*.google.com，并设置合适的证书过期时间 2、攻击者等待访问者的浏览器访问Gmail时，通过DNS劫持或IP伪造（对于有路由器控制权限的黑客来说简直轻而易举）的方法使其访问到攻击者的服务器上 3、攻击者把伪造的SSL证书公钥发送给浏览器 4、浏览器验证SSL证书的域和过期时间都没错，认为访问到的就是Gmail本身，从而把对称密钥发送给黑客服务器 5、黑客服务器把伪造的Gmail网页通过收到的对称密钥加密后发送给浏览器 6、访问者通过浏览器输入Gmail帐户，发送给黑客服务器，黑客服务器通过收到的对称密钥解密后成功获得访问者的Gmail密码 为了抵御这种中间人攻击，SSL证书需要由可信的SSL证书颁发机构颁发，形成一个证书链（比如Gmail的证书链为：最底层为网域mail.google.com，上一层为Thawte SGC CA证书颁发机构，最顶层为很有名的VeriSign证书颁发机构）。那么，浏览器除了需要验证域和有效期外，还要检查证书链中的上级证书公钥是否有效，上级的上级证书公钥是否有效，直至根证书公钥为止。这样就可以有效避免中间人攻击了，因为根证书公钥都是预装在操作系统中的，黑客如果不是暴力破解，无法得到根证书的私钥，如果黑客自己生成一个私钥，浏览器验证根证书公钥的时候发现无法通过操作系统中预装的公钥加密数据后使用这个私钥进行解密，从而判定这个公钥是无效的。这个方案也是现在https通讯通常的方案。 那么，这个现在所有的浏览器正在使用的https通讯方案就无懈可击了吗？答案仍是否定的。我们可以看到，在后一个方案中，https的安全性需要在证书颁发机构公信力的强有力保障前提下才能发挥作用。如果证书颁发机构在没有验证黑客为mail.google.com的持游者的情况下，给黑客颁发了网域为mail.google.com的证书，那么黑客的中间人攻击又可以顺利实施： |
|
|
