确保Web安全的HTTPS，在HTTP协议中可能存在信息窃听或身份伪装等安全问题。使用HTTPS通信机制可以有效的避免这些问题。一、HTTP的缺点HTTP主要有这些不足，例如：通信采用明文（未加密），内容可能在不验证通信方身份的情况下被窃听，因此可能遇到伪装，无法证明完整性的消息，因此存在可能被篡改HTTP缺点：使用明文通信可能被窃听由于HTTP本身不具备加密能力，因此也不可能对整个通信进行加密（使用HTTP协议通信的请求和响应的内容）.也就是说，HTTP消息以明文形式发送（指未加密的消息）。TCP/IP是一种可能被窃听的网络。如果要问为什么通信不加密，那就是吃亏了。这是因为，根据TCP/IP协议族的工作机制，所有通信线路上的通信内容都可能被窃听。所谓互联网，是由可以连接整个世界的网络组成的。无论服务器在世界的哪个角落与客户端通信，这条通信线路上的一些网络设备、光缆、电脑等都不可能是个人财产，所以不排除在某个特定的地方会有恶意偷窥行为关联。甚至可以查看加密的通信，就像未加密的通信一样。只是说，如果通信是加密的，人们可能无法破译消息信息的含义，但加密后的消息信息本身还是会被看到。图：互联网上的任何地方都存在通信窃听的风险。窃听同一网段的通信并不困难。只是收集在互联网上流动的数据包（帧）。对收集到的数据包的分析可以交给那些包捕获（PacketCapture）或嗅探器（Sniffer）工具。下图是目前广泛使用的抓包工具Wireshark的示例。它可以获取HTTP协议请求和响应的内容并进行解析。可以做一系列的事情，比如使用GET方法发送请求，返回200OK响应，查看HTTP响应报文的全部内容等等。防止窃听的加密处理在大家正在研究的防止窃听和保护信息的几种对策中，加密技术是最受欢迎的。可以有多个加密对象。加密通信线路的一种方法是加密通信。HTTP协议中没有加密机制，但可以结合SSL（SecureSocketLayer）或TLS（TransportLayerSecurity）对HTTP通信内容进行加密。一旦使用SSL建立了安全通信线路，就可以通过该线路进行HTTP通信。HTTP与SSL结合称为HTTPS（安全HTTP）或HTTPoverSSL。内容的加密还有一种加密参与通信的内容本身的方式。由于HTTP协议中没有加密机制，所以HTTP协议本身传输的内容是加密的。即HTTP报文中包含的内容是加密的。在这种情况下，客户端需要在发送请求之前对HTTP消息进行加密。的确，要实现有效的内容加密，前提是客户端和服务端都需要有加解密机制。主要用于网络服务。必须注意的是，由于这种方式不同于对整个通信线路进行加密的SSL或TLS，因此内容仍然存在被篡改的风险。2、如果不核实通讯方身份，可能会遇到伪造。HTTP协议中的请求和响应不会确认通信方。也就是说，存在类似“服务器是否是发送请求中URI指定的真实主机，返回的响应是否真的返回给实际发出请求的客户端”等类似问题。任何人都可以发起请求。通过HTTP协议进行通信时，由于没有确认通信方的处理步骤，任何人都可以发起请求。另外，只要服务器收到请求，不管对方是谁，都会返回一个响应（但前提是发送端的IP地址和端口号不受Web服务器的限制）。HTTP协议本身的实现非常简单。无论是谁发出请求，都会返回一个响应。因此，如果不确认通信方，就会存在以下隐患：无法确定向目标发送请求的Web服务器是否是按照真实意图返回响应的Web服务器。服务器。可能是一个伪装的网络服务器。无法确定收到响应的客户端是否是按预期收到响应的客户端。可能是伪装客户。无法确定正在通信的另一方是否具有访问权限。由于重要信息存储在某些Web服务器上，因此只有某些用户有权进行通信。无法确定请求来自何处以及由谁发出。即使是毫无意义的请求也会被接受。无法防止海量请求下的DoS攻击（DenialofService，拒绝服务攻击）。识别对方的证书虽然使用HTTP协议无法识别通信方，但如果使用SSL则可以。SSL不仅提供加密，而且还使用一种称为证书的方式来识别一方。证书由受信任的第三方组织颁发，以证明服务器和客户端确实存在。此外，从技术角度来看，伪造证书难度极大。因此，只要能够确认通信方（服务器或客户端）持有的证书，就可以判断通信方的真实意图。通过使用证书，来证明通信方是预期的服务器。这也降低了个人用户个人信息泄露的风险。此外，客户端可以通过持有证书完成个人身份的确认，也可以用于网站的身份验证过程。3.无法证明消息的完整性，可能被篡改过。所谓完整性，是指信息的准确性。无法证明其完整性通常意味着无法确定信息是否准确。收到的内容可能不正确。由于HTTP协议无法证明通信报文的完整性，因此在请求或响应发出后到对方收到之前的这段时间里，即使请求或响应的内容是否被篡改，也无从知晓。换句话说，没有办法来确认发送的请求/响应和接收到的请求/响应是否相同。例如，从某个网站下载内容时，无法判断客户端下载的文件与服务器端存储的文件是否一致。文件内容可能在传输过程中被其他内容篡改。即使内容真的发生了变化，接收客户端也不会察觉。像这样，请求或响应被攻击者截获并在传输过程中篡改内容的攻击称为中间人攻击（Man-in-the-Middleattack，MITM）。4、如何防止篡改虽然有一种利用HTTP协议来判断消息完整性的方法，但实际上并不方便可靠。最常用的方法是MD5和SHA-1等哈希值验证方法，以及用于确认文件的数字签名方法。提供文件下载服务的网站也会提供相应的用PGP（PrettyGoodPrivacy）创建的数字签名和MD5算法生成的哈希值。PGP是用来证明文件创建的数字签名，MD5是单向函数生成的哈希值。无论使用哪种方式，都需要操作客户端的用户亲自核实下载的文件是否为原服务器上的文件。浏览器无法自动检查用户。遗憾的是，通过这些方法，仍然无法保证确认结果的正确性。由于PGP和MD5被改写，用户无法实现。为了有效地防止这些滥用，使用HTTPS是很有必要的。SSL提供认证和加密处理以及摘要功能。单独使用HTTP很难保证完整性，所以它与其他协议结合使用来实现这一目标。2.HTTP+加密+认证+完整性保护=HTTPS1.HTTP加上加密处理和认证及完整性保护就是HTTPS。如果在HTTP协议通信过程中使用了未加密的明文，比如在网页中输入信用卡号，如果这条通信线路被窃听，信用卡号就会暴露。另外，对于HTTP，无论是服务端还是客户端，都没有办法确认通信方。因为很有可能你实际上并没有和原本期待的沟通对象进行沟通。并且还需要考虑接收到的消息在通信过程中被篡改的可能性。为了统一解决上述问题，需要在HTTP中加入加密处理、鉴权等机制。我们将添加了加密和认证机制的HTTP称为HTTPS（HTTPSecure）。HTTPS通信通常用于Web登录页面、购物结帐屏幕等。使用HTTPS通信时，请使用https://而不是http://。此外，当浏览器访问启用了HTTPS通信的网站时，浏览器的地址栏中会出现锁定标记。HTTPS的显示方式因浏览器而异。2.HTTPS是套在SSL外壳中的HTTPHTTPS并不是应用层的新协议。只有HTTP通信接口部分被SSL（安全套接字层）和TLS（安全传输层）协议取代。通常，HTTP直接与TCP通信。在使用SSL时，演变为先用SSL通信，再用SSL和TCP通信。简而言之，所谓HTTPS，其实就是包裹在SSL协议外壳中的HTTP。通过采用SSL，HTTP具有HTTPS的加密、证书和完整性保护功能。SSL是一个独立于HTTP的协议，因此不仅HTTP协议，其他运行在应用层的协议如SMTP、Telnet等都可以与SSL协议一起使用。可以说，SSL是当今世界上使用最广泛的网络安全技术。3、相互交换密钥的公钥加密技术在讲解SSL之前，我们先来了解一下加密方式。SSL使用称为公钥加密的加密过程。在现代加密方法中，加密算法是公开的，但密钥是保密的。这样，加密方法的安全性得以保持。加密和解密都使用密钥。密码没有密钥就无法解密，反之，任何人只要有密钥就可以解密。如果密钥被攻击者获取，加密就没有意义。共享密钥加密的困境加密和解密使用相同密钥的方式称为共享密钥加密（Commonkeycryptosystem），也称为对称密钥加密。使用共享密钥加密时，密钥也必须发送给对方。怎样才能安全移交？当密钥在互联网上转发时，如果通信被拦截，密钥就可能落入攻击者手中，加密的意义也就失去了。另外，请尽量妥善保管收到的密钥。使用两个密钥的公钥加密公钥加密很好地解决了共享密钥加密的难点。公钥加密使用一对非对称密钥。一个称为私钥，另一个称为公钥。顾名思义，私钥不能被其他任何人知道，而公钥可以随意发布，任何人都可以获得。使用公钥加密方式，发送密文的一方使用对方的公钥进行加密，对方收到后使用自己的私钥对加密信息进行解密。这样就不需要发送用于解密的私钥，也不用担心密钥被攻击者窃听窃取。另外，基于密文和公钥来还原信息的原文是非常困难的，因为解密过程是求离散对数，不容易做到。退一步说，如果一个非常大的整数可以快速因式分解，那么密码破解还是有希望的。但以目前的技术来看是不现实的。HTTPS使用混合加密机制HTTPS使用混合加密机制，它使用共享密钥加密和公钥加密。如果可以安全地交换密钥，则可以考虑仅使用公钥加密进行通信。但是，公钥加密的处理速度比共享密钥加密慢。因此，我们应该充分利用各自的优势，将多种沟通方式结合起来。在密钥交换环节采用公钥加密方式，在后续的通信建立和消息交换阶段采用共享密钥加密方式。4.证明公钥正确性的证书不幸的是，公钥加密方法还存在一些问题。也就是说，无法证明公钥本身是真正的公钥。例如，准备与某台服务器建立公钥加密通信时，如何证明收到的公钥就是原先期望的服务器颁发的公钥。可能在公钥传输过程中，真正的公钥已经被攻击者换掉了。为了解决上述问题，可以使用数字证书认证机构（CA，CertificateAuthority）及相关机构颁发的公钥证书。数字证书认证机构处于客户端和服务器都信任的第三方位置。威瑞信（VeriSign）是知名的数字证书认证机构之一。下面介绍一下数字证书认证机构的业务流程。首先，服务器运营商向数字证书认证机构申请公钥。数字证书认证机构在识别申请者的身份后，会对申请的公钥进行数字签名，然后分发签名后的公钥，并将公钥放入公钥证书中绑定到Together上。服务器将数字证书认证机构颁发的这个公钥证书发送给客户端进行公钥加密通信。公钥证书也可以直接称为数字证书或证书。收到证书的客户端可以使用数字证书证书颁发机构的公钥来验证该证书上的数字签名。一旦验证通过，客户端可以确认两件事：1.认证服务器公钥的身份是真实有效的数字证书认证机构。其次，服务器的公钥是可信的。此处证书颁发机构的公钥必须安全地传输给客户端。在使用通讯方式的时候，如何安全的传输是一件非常困难的事情。因此，大多数浏览器开发者在发布一个版本时，都会提前在里面嵌入常用的证书颁发机构的公钥。EVSSL证书证书能够证明机构真实性的一个作用是证明作为通信方的服务器是否规范，另一个作用是确认对方服务器背后运行的企业是否真实存在。具有此功能的证书是EVSSL证书（扩展验证SSL证书）。EVSSL证书是根据国际标准认证指南颁发的。它严格规定了运营机构真实性的验证政策，因此通过认证的网站可以获得更高的认可度。持有EVSSL证书的网站，浏览器地址栏的背景色为绿色，一目了然。此外，在地址栏的左侧，显示记录在SSL证书中的组织名称和颁发证书的证书颁发机构的名称。上述机制的初衷是为了防止用户受到网络钓鱼（Phishing）的攻击，但在效果上，还有一个问号。很多用户可能对EVSSL证书并不了解，所以也没有太在意。用于识别客户端的客户端证书客户端证书也可用于HTTPS。使用客户端证书进行客户端身份验证证明服务器一直在与预期的客户端进行通信，其作用与服务器证书的作用完全相同。但是，客户端证书仍然存在一些问题。问题点之一是证书的获取和颁发。要获得证书，用户必须自己安装客户端证书。但是，由于客户端证书是付费购买的，而且每个证书对应每个用户，这意味着需要支付与用户数量相等的费用。此外，让不同知识水平的用户自行安装证书也充满挑战。现状是高度安全的证书颁发机构可以颁发客户端证书，但仅限于特殊用途的业务。比如那些可以支持客户端凭证支付的服务。例如，银行的网上银行使用客户证书。用户在登录网上银行时，不仅需要确认用户名和密码的输入，还需要用户的客户端证书，以确认用户是否从特定终端访问网上银行。客户端证书的另一个问题是，毕竟客户端证书只能用来证明客户端的真实存在，而不能证明用户本人的真实性。也就是说，只要您有权使用安装了客户端证书的计算机，您也有权使用该客户端证书。认证机构的信誉至上。认证机构之所以参与SSL机制是可行的，是因为它建立在其信用绝对可靠的前提下。然而，2011年7月，荷兰一家名为DigiNotar的证书颁发机构遭到非法入侵，为google.com和twitter.com等网站颁发了假证书。这一事件从根本上动摇了SSL的可信度。因为假证书有正规证书颁发机构的数字签名，浏览器会判断该证书是合法的。当伪造的证书被用作服务器伪装时，用户根本无法察觉。虽然有可以使证书失效的证书撤销列表（CRL）机制，以及从客户端中删除根证书颁发机构（RCA）的反制措施，但它需要一些时间才能生效，而在一段时间内，它是不知道会损失多少用户的利益。由自认证机构颁发的证书称为自签名证书。如果使用OpenSSL开源程序，每个人都可以建立一套自己的证书颁发机构来颁发自己的服务器证书。但是该服务器证书在互联网上无法作为证书使用，似乎没有帮助。独立构建的证书颁发机构称为自认证机构，自认证机构颁发的“无用”证书也被戏称为自签名证书。当浏览器访问服务器时，会显示“无法确认连接的安全性”或“此网站的安全证书有问题”等警告信息。自我认证机构颁发的服务器证书不起作用，因为它不能消除伪装的可能性。一个自证机构所能产生的效果，至多是对外宣称“我是○○”的程度。即使是自签名证书，经过SSL加密后，偶尔也会看到通信处于安全状态的提示，但这也是有问题的。因为即使通信是加密的，也不排除是在和经过伪装的假服务器保持通信。只有可信的第三方机构介入认证，才能使用植入浏览器的认证机构颁发的公钥来证明服务器的真实性。来自中间CA的证书可能成为自认证证书。大多数浏览器都预装了可信CA的证书，但也有少数浏览器预装了中间CA的证书。对于中间证书颁发机构颁发的服务器证书，有的浏览器会把它当作正式证书，有的浏览器会把它当作自签名证书。5、HTTPS安全通信机制HTTPS通信步骤：第一步：客户端通过发送ClientHello报文开始SSL通信。该消息包含客户端支持的指定SSL版本，以及密码套件列表（使用的加密算法、密钥长度等）。第二步：当服务器可以进行SSL通信时，它会响应一个ServerHello消息。与客户端一样，SSL版本和加密组件包含在消息中。服务器的加密组件内容是从接收到的客户端加密组件中过滤出来的。第三步：然后服务器发送一个Certificate消息。该消息包含公钥证书。第四步：最后，服务器发送ServerHelloDone消息通知客户端，SSL握手协商的初始阶段结束。第5步：在第一次SSL握手结束后，客户端以ClientKeyExchange消息响应。该消息包含一个称为Pre-mastersecret的随机密码字符串，用于通信加密。此消息已使用第3步中的公钥加密。第6步：然后客户端继续发送ChangeCipherSpec消息。这条消息会提示服务器，这条消息之后的通信会被Pre-mastersecretkey加密。第七步：客户端发送Finished消息。此消息包含到目前为止连接的所有消息的总体检查值。本次握手协商能否成功，以服务器能否正确解密消息为准绳。第8步：服务器还发送一个ChangeCipherSpec消息。第9步：服务器也发送Finished消息。第十步：服务端与客户端的Finished消息交互完成后，SSL连接建立。当然，通信由SSL保护。从这里开始应用层协议的通信，即发送HTTP请求。第十一步：应用层协议通信，即发送HTTP响应。第十二步：最后被客户端断开连接。断开连接时，发送close_notify消息。上图有些遗漏。此步骤后，将发送TCPFIN消息以关闭与TCP的通信。在上述过程中，应用层发送数据时，会附带一个消息摘要，称为MAC（MessageAuthenticationCode，消息认证码）。MAC可以检测消息是否被篡改，从而保护消息的完整性。下面是整个过程的图示。该图说明了仅使用服务器端公钥证书（服务器证书）建立HTTPS通信的整个过程。-SSL和TLSHTTPS使用两种协议，SSL（安全套接字层）和TLS（安全传输层）。SSL技术最初由浏览器开发商NetscapeCommunicationsCorporation首创，该公司开发了SSL3.0之前的版本。目前，主导权已经转移到IETF（InternetEngineeringTaskForce，互联网工程任务组）手中。IETF以SSL3.0为基准，后来发展了TLS1.0、TLS1.1、TLS1.2。TSL是基于SSL开发的协议，有时也统称为SSL。目前主流的版本是SSL3.0和TLS1.0。由于SSL1.0协议在设计之初就被发现存在问题，因此并未真正投入使用。SSL2.0也被发现有问题，所以很多浏览器直接废掉了这个版本的协议。SSL慢吗？HTTPS也有一些问题，就是使用SSL时，处理起来会比较慢。有两种类型的慢速SSL。一是指沟通缓慢。另一种是CPU、内存等资源大量消耗导致处理速度变慢。网络负载可能比使用HTTP慢2到100倍。除了用TCP连接和发送HTTP请求?响应外，还必须进行SSL通信，因此整体处理流量不可避免地会增加。还有一点就是SSL必须加密。服务端和客户端都需要进行加解密操作。因此，结果会比HTTP消耗更多的服务器和客户端的硬件资源，导致负载增加。减速没有根本的解决方案，我们使用（专用服务器）硬件，如SSL加速器来改善它。硬件专用于SSL通信，相对于软件，可以将SSL的计算速度提高数倍。仅将SSL加速器用于SSL处理以分担负载。为什么不总是使用HTTPS既然HTTPS如此安全，为什么不是所有网站都一直使用HTTPS？原因之一是因为加密通信比纯文本通信消耗更多的CPU和内存资源。如果每次通信都加密，会消耗大量的资源，而当它在一台计算机上传播时，可处理的请求数肯定会相应减少。因此，对于非敏感信息使用HTTP通信，只有在包含个人信息等敏感数据时才使用HTTPS加密通信。尤其是当那些访问量大的网站被加密时，其所承受的负载更是不容小觑。加密时，并不是所有的内容都加密，只有在需要隐藏信息时才加密，以节省资源。此外，其中一个原因是可以节省购买证书的成本。HTTPS通信需要证书。使用的证书必须从证书颁发机构(CA)购买。证书价格可能因认证机构而略有不同。通常，一年的授权需要数万日元（现在1万日元约合人民币600元）。那些购买证书不划算的服务和一些个人网站可能只能选择使用HTTP作为通信方式。以下是之前学习的总结，有需要的朋友可以去看看~~TCP/IP基础总结学习（一）：了解web和网络基础https://segmentfault.com/a/11...TCP/IP基础知识总结学习（二）：简单HTTP协议https://segmentfault.com/a/11...TCP/IP基础总结学习（三）：HTTP报文中的HTTP信息https://segmentfault.com/a/11...TCP/IP基础总结学习（四）：返回结果的HTTP状态码https://segmentfault.com/a/11...TCP/IP基础总结学习（五）：Webserverthat配合HTTPhttps://segmentfault.com/a/11...TCP/IP基础总结学习（六）：配合HTTPhttps://segmentfault.com/a/11的Web服务器。..前端实践面试题总结：https://segmentfault.com/a/11...
