这篇文章给大家聊聊关于域名污染影响同源码分享网站么，以及域名被污染是什么原因对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
文章目录
★相关背景知识★HTTPS协议的需求是啥？★设计HTTPS协议的主要难点★结尾
★相关背景知识
要说清楚HTTPS协议的实现原理，至少需要如下几个背景知识。1.大致了解几个基本术语（HTTPS、SSL、TLS）的含义2.大致了解HTTP和TCP的关系（尤其是“短连接”VS“长连接”）3.大致了解加密算法的概念（尤其是“对称加密与非对称加密”的区别）4.大致了解CA证书的用途考虑到很多技术菜鸟可能不了解上述背景，俺先用最简短的文字描述一下。如果你自认为不是菜鸟，请略过本章节，直接去看“HTTPS协议的需求”。
◇先澄清几个术语——HTTPS、SSL、TLS
1.“HTTP”是干嘛用滴？首先，HTTP是一个网络协议，是专门用来帮你传输Web内容滴。关于这个协议，就算你不了解，至少也听说过吧？比如你访问俺的博客的主页，浏览器地址栏会出现如下的网址http://program-think.blogspot.com/俺加了粗体的部分就是指HTTP协议。大部分网站都是通过HTTP协议来传输Web页面、以及Web页面上包含的各种东东（图片、CSS样式、JS脚本）。2.“SSL/TLS”是干嘛用滴？SSL是洋文“SecureSocketsLayer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。（顺便插一句，网景公司不光发明了SSL，还发明了很多Web的基础设施——比如“CSS样式表”和“JS脚本”）为啥要发明SSL这个协议捏？因为原先互联网上使用的HTTP协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明SSL协议，就是为了解决这些问题。到了1999年，SSL因为应用广泛，已经成为互联网上的事实标准。IETF就在那年把SSL标准化。标准化之后的名称改为TLS（是“TransportLayerSecurity”的缩写），中文叫做“传输层安全协议”。很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。3.“HTTPS”是啥意思？解释完HTTP和SSL/TLS，现在就可以来解释HTTPS啦。咱们通常所说的HTTPS协议，说白了就是“HTTP协议”和“SSL/TLS协议”的组合。你可以把HTTPS大致理解为——“HTTPoverSSL”或“HTTPoverTLS”（反正SSL和TLS差不多）。
◇再来说说HTTP协议的特点
作为背景知识介绍，还需要再稍微谈一下HTTP协议本身的特点。HTTP本身有很多特点，考虑到篇幅有限，俺只谈那些和HTTPS相关的特点。1.HTTP的版本和历史如今咱们用的HTTP协议，版本号是1.1（也就是HTTP1.1）。这个1.1版本是1995年底开始起草的（技术文档是RFC2068），并在1999年正式发布（技术文档是RFC2616）。在1.1之前，还有曾经出现过两个版本“0.9和1.0”，其中的HTTP0.9【没有】被广泛使用，而HTTP1.0被广泛使用过。另外，据说IETF就要发布HTTP2.0的标准了。俺拭目以待。2.HTTP和TCP之间的关系简单地说，TCP协议是HTTP协议的基石——HTTP协议需要依靠TCP协议来传输数据。在网络分层模型中，TCP被称为“传输层协议”，而HTTP被称为“应用层协议”。有很多常见的应用层协议是以TCP为基础的，比如“FTP、SMTP、POP、IMAP”等。TCP被称为“面向连接”的传输层协议。关于它的具体细节，俺就不展开了（否则篇幅又失控了）。你只需知道：传输层主要有两个协议，分别是TCP和UDP。TCP比UDP更可靠。你可以把TCP协议想象成某个水管，发送端这头进水，接收端那头就出水。并且TCP协议能够确保，先发送的数据先到达（与之相反，UDP不保证这点）。3.HTTP协议如何使用TCP连接？HTTP对TCP连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，洋文叫做“Keep-Alive”或“PersistentConnection”）假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS文件和JS文件。在“短连接”的模式下，浏览器会先发起一个TCP连接，拿到该网页的HTML源代码（拿到HTML之后，这个TCP连接就关闭了）。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。然后针对【每一个】外部资源，再分别发起一个个TCP连接，把这些文件获取到本地（同样的，每抓取一个外部资源后，相应的TCP就断开）相反，如果是“长连接”的方式，浏览器也会先发起一个TCP连接去抓取页面。但是抓取页面之后，该TCP连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。然后浏览器分析HTML源码之后，发现有很多外部资源，就用刚才那个TCP连接去抓取此页面的外部资源。在HTTP1.0版本，【默认】使用的是“短连接”（那时候是Web诞生初期，网页相对简单，“短连接”的问题不大）；到了1995年底开始制定HTTP1.1草案的时候，网页已经开始变得复杂（网页内的图片、脚本越来越多了）。这时候再用短连接的方式，效率太低下了（因为建立TCP连接是有“时间成本”和“CPU成本”滴）。所以，在HTTP1.1中，【默认】采用的是“Keep-Alive”的方式。关于“Keep-Alive”的更多介绍，可以参见维基百科词条
◇谈谈“对称加密”和“非对称加密”的概念
1.啥是“加密”和“解密”？通俗而言，你可以把“加密”和“解密”理解为某种【互逆的】数学运算。就好比“加法和减法”互为逆运算、“乘法和除法”互为逆运算。“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”。在这两个过程中，都需要一个关键的东东——叫做“密钥”——来参与数学运算。2.啥是“对称加密”？所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用【相同的】密钥。这个比较好理解。就好比你用7zip或WinRAR创建一个带密码（口令）的加密压缩包。当你下次要把这个压缩文件解开的时候，你需要输入【同样的】密码。在这个例子中，密码/口令就如同刚才说的“密钥”。3.啥是“非对称加密”？所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用【不同的】密钥。这玩意儿比较难理解，也比较难想到。当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。由于篇幅有限，对“非对称加密”这个话题，俺就不展开了。有空的话，再单独写一篇扫盲。4.各自有啥优缺点？看完刚才的定义，很显然：（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多。这是“非对称加密”的优点。但是“非对称加密”的实现，通常需要涉及到“复杂数学问题”。所以，“非对称加密”的性能通常要差很多（相对于“对称加密”而言）。这两者的优缺点，也影响到了SSL协议的设计。
◇CA证书的原理及用途
关于这方面，请看俺写的《数字证书及CA的扫盲介绍》。这里就不再重复唠叨了，免得篇幅太长。
★HTTPS协议的需求是啥？
花了好多口水，终于把背景知识说完了。下面正式进入正题。先来说说当初设计HTTPS是为了满足哪些需求？很多介绍HTTPS的文章一上来就给你讲实现细节。个人觉得：这是不好的做法，开公众号的时候，发过一篇《学习技术的三部曲：WHAT、HOW、WHY》，其中谈到“WHY型问题”的重要性。一上来就给你讲协议细节，你充其量只能知道WHAT和HOW，无法理解WHY。俺在前一个章节讲了“背景知识”，在这个章节讲了“需求”，这就有助于你理解：当初为什么要设计成这样？——这就是WHY型的问题。
◇兼容性
因为是先有HTTP再有HTTPS。所以，HTTPS的设计者肯定要考虑到对原有HTTP的兼容性。这里所说的兼容性包括很多方面。比如已有的Web应用要尽可能无缝地迁移到HTTPS；比如对浏览器厂商而言，改动要尽可能小；……基于“兼容性”方面的考虑，很容易得出如下几个结论：1.HTTPS还是要基于TCP来传输（如果改为UDP作传输层，无论是Web服务端还是浏览器客户端，都要大改，动静太大了）2.单独使用一个新的协议，把HTTP协议包裹起来（所谓的“HTTPoverSSL”，实际上是在原有的HTTP数据外面加了一层SSL的封装。HTTP协议原有的GET、POST之类的机制，基本上原封不动）
打个比方：如果原来的HTTP是塑料水管，容易被戳破；那么如今新设计的HTTPS就像是在原有的塑料水管之外，再包一层金属水管。一来，原有的塑料水管照样运行；二来，用金属加固了之后，不容易被戳破。
◇可扩展性
前面说了，HTTPS相当于是“HTTPoverSSL”。如果SSL这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟HTTP搭配，还能够跟其它的应用层协议搭配。岂不美哉？现在看来，当初设计SSL的人确实比较牛。如今的SSL/TLS可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。接着刚才打的比方：如果把SSL/TLS视作一根用来加固的金属管，它不仅可以用来加固输水的管道，还可以用来加固输煤气的管道。
◇保密性（防泄密）
HTTPS需要做到足够好的保密性。说到保密性，首先要能够对抗嗅探（行话叫Sniffer）。所谓的“嗅探”，通俗而言就是监视你的网络传输流量。如果你使用明文的HTTP上网，那么监视者通过嗅探，就知道你在访问哪些网站的哪些页面。嗅探是最低级的攻击手法。除了嗅探，HTTPS还需要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”（后面讲协议原理的时候，会再聊）。
◇完整性（防篡改）
除了“保密性”，还有一个同样重要的目标是“确保完整性”。关于“完整性”这个概念，在之前的博文《扫盲文件完整性校验——关于散列值和数字签名》中大致提过。健忘的同学再去温习一下。在发明HTTPS之前，由于HTTP是明文的，不但容易被嗅探，还容易被篡改。举个例子：比如咱们天朝的网络运营商（ISP）都比较流氓，经常有网友抱怨说访问某网站（本来是没有广告的），竟然会跳出很多中国电信的广告。为啥会这样捏？因为你的网络流量需要经过ISP的线路才能到达公网。如果你使用的是明文的HTTP，ISP很容易就可以在你访问的页面中植入广告。所以，当初设计HTTPS的时候，还有一个需求是“确保HTTP协议的内容不被篡改”。
◇真实性（防假冒）
在谈到HTTPS的需求时，“真实性”经常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。举个例子：你因为使用网银，需要访问该网银的Web站点。那么，你如何确保你访问的网站确实是你想访问的网站？（这话有点绕口令）有些天真的同学会说：通过看网址里面的域名，来确保。为啥说这样的同学是“天真的”？因为DNS系统本身是不可靠的（尤其是在设计SSL的那个年代，连DNSSEC都还没发明）。由于DNS的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名【未必】是真实滴！（不了解“域名欺骗”和“域名劫持”的同学，可以参见俺之前写的《扫盲DNS原理，兼谈“域名劫持”和“域名欺骗/域名污染”》）所以，HTTPS协议必须有某种机制来确保“真实性”的需求（至于如何确保，后面会细聊）。
◇性能
再来说最后一个需求——性能。引入HTTPS之后，【不能】导致性能变得太差。否则的话，谁还愿意用？为了确保性能，SSL的设计者至少要考虑如下几点：1.如何选择加密算法（“对称”or“非对称”）？2.如何兼顾HTTP采用的“短连接”TCP方式？（SSL是在1995年之前开始设计的，那时候的HTTP版本还是1.0，默认使用的是“短连接”的TCP方式——默认不启用Keep-Alive）
◇小结
以上就是设计SSL协议时，必须兼顾的各种需求。后面聊协议的实现时，俺会拿SSL协议的特点跟前面的需求作对照。看看这些需求是如何一一满足滴。
★设计HTTPS协议的主要难点
设计HTTPS这个协议，有好几个难点。俺个人认为最大的难点在于“密钥交换”。在传统的密码学场景中，假如张三要跟李四建立一个加密通讯的渠道，双方事先要约定好使用哪种加密算法？同时也要约定好使用的密钥是啥？在这个场景中，加密算法的【类型】让旁人知道，没太大关系。但是密钥【千万不能】让旁人知道。一旦旁人知道了密钥，自然就可以破解通讯的密文，得到明文。好，现在回到HTTPS的场景。当你访问某个公网的网站，你的浏览器和网站的服务器之间，如果要建立加密通讯，必然要商量好双方使用啥算法，啥密钥。——在网络通讯术语中，这个过程称之为“握手/handshake”。在握手阶段，因为加密方式还没有协商好，所以握手阶段的通讯必定是【明文】滴！既然是明文，自然有可能被第三方偷窥到。然后，还要考虑到双方之间隔着一个互联网，什么样的偷窥都可能发生。因此，在握手的过程中，如何做到安全地交换密钥信息，而不让周围的第三方看到。这就是设计HTTPS最大的难点。
★结尾
本文费这么多口水，来介绍HTTPS的“需求”和“难点”，为啥捏？因为只有当你了解这些，后面介绍SSL/TLS的实现原理时，你才能理解——当初为啥要把协议设计成这个样子。
关于域名污染影响同源码分享网站么，域名被污染是什么原因的介绍到此结束，希望对大家有所帮助。