Ghost Assassin:《(基础知识)SSL/TLS的原理以及互联网究竟是如何工作的》1~6

SSL/TLS的原理以及互联网究竟是如何工作的(1) ——“每个协议生而平等”

我曾经写过介绍HTTPS原理的文章[1] ,但那篇文章大部分直接摘自WIKI,比较难懂外加篇幅过长,所以我这次专门新开一个系列具体描述一下究竟HTTPS是怎么回事以及介绍一些计算机网络的概念(尤其是澄清一些错误概念)。

计算机网络里有一个模型非常有名:OSI(Open Systems Interconnection,开放系统互连)模型,几乎所有的计算机网络教学和科研都要在OSI的基础上进行,想要讨论计算机网络中的问题也要依靠这个模型。

OSI模型是这样的结构(从底层到最高层)[2][3]:

1,物理层(physical layer)
物理层负责最后将信息编码成电流脉冲或其它信号用于网上传输。它由计算机和网络介质之间的实际界面组成,可定义电气信号、符号、线的状态和时钟要求、数据编码和数据传输用的连接器。有线网络信号有电流脉冲(电缆传输)和电磁脉冲(光纤传输)两种。物理层由物理存在的传输介质(例如网线)和设备(例如网卡,路由器)组成。

2,数据链路层(data link layer)
数据链路层通过物理网络链路提供可靠的数据传输。不同的数据链路层定义了不同的网络和协议特征,其中包括物理编址、网络拓扑结构、错误校验、帧序列以及流控。数据链路层实际上由两个独立的部分组成,介质存取控制(Media Access Control,MAC)和逻辑链路控制层(Logical Link Control,LLC)。数据链路层负责在物理层上建立通信链路(每次打开浏览器联网就是建立了数据链路,关闭浏览器之后相应的数据链路就不存在了)。PPP(点对点协议)就在数据链路层上。

3,网络层(network layer)
网络层负责在源和终点之间建立连接,为不同主机提供逻辑通信。它一般包括网络寻径,还可能包括流量控制、错误检查等。网络层只负责建立连接,并不保证连接的可靠性。大名鼎鼎的IP(互联网协议)就在网络层。

4,传输层(transport layer)
在 OSI 模型中传输层是负责数据通信的最高层,是惟一负责总体数
据传输和控制的一层,保证连接的可靠性,直接给运行在不同主机
上的应用程序提供通信服务。与IP齐名的TCP(传输控制协议)和UDP(用户数据报协议)就工作在传输层上,SSL/TLS也工作在传输层上。顺便说一句,加密连接几乎都是依靠传输层的(不管是什么样的加密),加密过程也是在传输层上完成的。

5,会话层(session layer)
会话层在两个节点间建立、维护和释放面向用
户的连接,对进行会话的两台机器间建立对话控制,管理会话如管
理哪边发送、何时发送、占用多长时间等,保证会话数据可靠传送。它还包括创建检查点,使通信发生中断的时候可以返回到以前的一个状态。

6,表示层(presentation layer)
表示层是处理所有与数据表示及传输有关的一层,为异种机
通信提供一种公共语言,为上层用户提供数据信息的语法表示变
换,屏蔽不同计算机在信息表示方面的差异,即用一种大家一致同
意的标准方法对数据编码。表示层协议一般不与特殊的协议栈关联,如QuickTime是Applet计算机的视频和音频的标准,MPEG是ISO的视频压缩与编码标准。常见的图形图像格式PCX、GIF、JPEG是不同的静态图像压缩和编码标准。

7,应用层(application layer)
OSI模型的最高层,应用层的功能一般包括标识通信伙伴、定义资源的可用性和同步通信。注意,应用层并非由计算机上运行的实际应用软件组成,而是由向应用程序提供访问网络资源的API(Application Program Interface,应用程序接口)组成。应用层协议有著名的HTTP(超文本传输协议,网页传输就靠他),FTP(文件传输协议,很方便下载),SMTP(简单邮件传输协议,邮件他负责)等。

有些人看到这里大概就会这么想:原来OSI模型这么层次分明啊,就像公司里的上下级或者说军队里的各级军官和士兵一样,下级要听上级的,下级更管不了上级,只要把上级搞定了,下级怎么努力都没用。

大错特错!
OSI模型其实不仅在物理上不存在(硬件),逻辑上也不存在(软件),这只是一个为了简化通信这个大问题而用层级把大问题分成一个个小问题然后分而治之的概念模型而已!
也就是说,实际上根本就没有所谓的上下层存在,更没有上下级这一说!

那么实际上是怎样一个场景呢?

一群拥有不同技能的人聚集在一起,他们相互之间都是好朋友。

有一天,他们接到了一个任务:将重要的数据从A地安全传到半个地球以外的B地。
“这问题太大了,怎么解决啊?”“(我)别急,一步步想,肯定有办法的。”
众物理介质(光缆,中继器等):“我可以在物理层面把A地和B地的终端连接起来。”“(我)这是第一步,但还远远不够呢!对了,你们人数众多,一个个叫名字太麻烦了,就把你们统称为物理层吧!”

MAC和LLC:“我可以在物理层工作的基础上建立数据链路,实现直接相连的两个设备间的通信”PPP:“我可以实现点对点的数据链路!”“(我)很好,诸位,你们一起工作吧,你们的工作室的名字就叫数据链路层!”

“(我)可是A和B之间隔了半个地球啊,这要是直接连接,信号早就衰减的根本就无法传输到目的地了,怎么办呢?”’“不要忘了我啊,我可以实现间接连接的任意两点之间的通信,寻找最佳路径以及处理可能的堵车问题的活就交给我吧!””(我)是你啊,IP!””我可是很强大的,不过我没有办法保证一定能把数据送到目的地就是了,数据如果中途损坏出错丢失了,我可无能为力,而且我无法直接给应用程序提供通信服务。”“(我)那你也非常强大了,专门给你一个工作室吧,网络层工作室。”

”那么保证传输的可靠性的活就交给我吧!还有,让我来和那些应用程序打交道吧!““(我)你是?”“TCP!保证传输可靠性,我最在行了!我一定不会让任何一个数据报文(TCP数据单元)掉队的!”“我说TCP,你这点可是引起了相当多的视频爱好者的不满了,因为你,他们经常要为了一个马赛克多缓冲数秒钟,甚至有时路况(网络状况)不好,有一个数据报文没有送过来,然后你就不干了,后面那一大堆报文你都不肯接收,非要等着那一个送过来,真是可笑!”“我说UDP,那视频之类流媒体就交给你好了,你这个不可靠的家伙!”“(我)行了,两位别吵了,各有各的领域。你们的工作室,就叫传输层吧!”
“(我)还有两个终端之间的会话呢,谁来负责啊?”“我来吧,我还可以提供check point,要是一不小心断线了,也不用重新传输所有数据,我工作的地方叫会话层就行了!”“(我)OK!”
“(我)开始传输吧!等一下,A在说英文,B在说法文,根本就相互无法理解啊!怎么办呢?”“也就是说需要一个统一的标准,就让我们来吧,我们来提供一种大家都能听懂的公共语言!”“(我)啊,有好几位呢,文字的统一编码,视频的统一格式,图片的统一格式,你们一起吧,工作室叫表示层吧!”
“(我)差不多可以了吧?不行,还没有负责通过API最终把数据递给应用程序的人呢,还有最终的同步和通信伙伴(应用程序)的标识呢,不能把数据包送错了啊!”“我们可以帮这个忙!(异口同声)”我负责网页!“HTTP?”“下载和文件传输我最拿手!”“FTP?”“邮件就交给我处理吧!”“SMTP?”“(我)那好吧,你们待的工作室就叫应用层吧!”
“(我)这样就可以开始了!”“没错,大家一起,完成任务!我们各工作室一起处理好数据包,然后送出去!(异口同声)””(我)谁也离不开谁啊。好像这其中没有上下级呢。”“哪里需要什么上下级?大家每个人各司其职,一起负责A与B的终端的交流,谁也不能缺席,大家都是平等的,没有说什么谁领导谁,谁管理谁,谁管不了谁的事!”
“(我)是啊(笑),你们这些家伙可比像我这样的人类要明白多了,本来就没有谁应该骑在或被骑在谁的头上啊。”

互联网设计时重点放在连接上,几乎没有考虑安全,现在的各种加密协议以及身份验证机制都是后来补充上去的。

“等等,还有一个问题呢:数据传输时是明文的!那么传输过程中早就被第三方给看光了!还有,你都没有办法确定对方的身份!”’“(你看看我,我看看你)我们都不行。”“我来吧!”“SSL?”“我可以同时解决加密与身份验证的问题。”“那你想要去哪个工作室呢?”“这就难说了,加密解密和身份验证过程是需要和具体的应用程序配合完成的,但加密连接建立过程需要TCP的帮助,你可以认为我在传输层之上应用层之下,也就是说我是个复合协议。”“你要和TCP协同工作?”“没错。我所处理的,就是TCP数据报文,我所传递的,就是TCP数据流。我可以保证,除了传递数据的两方,其他人都无法得知数据内容,而且没人能冒充其中任何一方。”

“那你凭什么做出这样的保证呢?”“说来话长了,一时半会儿也说不清楚,以后我会慢慢说明的。”

接下来的系列里我会详细说明HTTPS连接究竟是怎么回事儿的,顺便再介绍一下实际使用的TCP/IP架构(OSI模型过于复杂,而且各层之间的分工其实并不是很明确,实际运用中很多时候各层都是混合的,所以TCP/IP将好几个层都合一了)。奉劝有些一知半解的半小白一句:计算机网络里相当多的模型或者架构或者协议都没法随便去与真实生活类比,在胡思乱想之前还是好好找一些专业资料读读吧!

最后照例附上科普文链接集合:https://plus.google.com/u/0/109790703964908675921/about

参考资料:
1,HTTP与HTTPS以及墙内的走狗网站们https://plus.google.com/109790703964908675921/posts/fgTznXwVfAw
2,https://en.wikipedia.org/wiki/OSI_model
3,通俗讲解 OSI 七层协议参考模型
http://202.120.43.103/downloads2/d3573339-0894-46b0-8059-762357eb328c.pdf

原文:https://plus.google.com/109790703964908675921/posts/jew5dx6V2Lt

===========

SSL/TLS的原理以及互联网究竟是如何工作的(2)——更合适的架构,大家一起努力!”

话说上回说到我和其他朋友们讨论来讨论去总算是大致解决了任意两台计算机之间的通信问题,不过又有新问题了:

“(我)诸位,我发现上次咱们是依据OSI模型讨论问题的,但这个模型其实并不是那么合适,有一些冗余之处。大家想一想,会话层和表示层实际上都是与应用程序配合工作的,而物理层那些纯硬件层面的问题其实并不是我们的领域,我们最多只要处理到与硬件的接口这一层次上就足够了。”“的确啊。”“(我)工作室需要合并一下:物理层与数据链路层合并为网络接口层,只负责硬件接口相关任务,硬件问题就不要去管它了;网络层改名为网络互连层,更为清晰;传输层不变;会话层,表示层和应用层合并为一层,统称应用层。”
现在实际使用的就是TCP/IP模型,也称作TCP/IP协议栈,由以下4层组成[1][2](这些层都不是真实存在的,只是一种抽象概念而已):

1,网络接口层
一般认为对应OSI模型中的物理层和数据链路层,但实际上TCP/IP标准并不定义与OSI数据链路层和物理层相对应的功能。相反,它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口,例如PC的网卡驱动程序。

2,网络互连层
一般认为对应OSI模型中的网络层,包含IP协议、RIP协议(Routing Information Protocol,路由信息协议),负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。注意,ICMP其实位于IP层之上,但它却是IP的附属协议,在OSI模型和TCP/IP协议栈中都没法放在一个合适的位置上。没办法,没有哪个模型是完美的。

3,传输层
一般认为对应OSI模型中的传输层,能够解决诸如端到端可靠性(“数据是否已经到达目的地?”)和保证数据按照正确的顺序到达这样的问题,也包括所给数据应该送给哪个应用程序。

4,应用层
一般认为对应OSI模型的会话层,表示层和应用层,该层包括所有和应用程序协同工作,利用基础网络交换应用程序专用的数据的协议。应用层的协议是要依赖传输层的协议工作的,应用层协议运行在传输层的TCP或UDP协议之上(这句话的意思是应用层协议负责打包封装数据提供给客户端或服务器端有用信息,再由传输层协议接过封包进行处理和传输)。

“(我)诸位,任务来了:A地的PC用户想要浏览网页,对应的网站服务器在半个地球之外的B地呢。开始吧!””我先处理用户的请求!(HTTP和其他几位(其中有原来的表示层工作室成员))”“我们一起建立可靠连接!(TCP和IP异口同声。PS:TCP和IP总是配合工作,TCP的查错机制中就有一步是对整个TCP段和伪段头(IP头的一部分)检查和,有些用户参数TCP直接传递给IP层处理),应用层的诸位,数据封装好之后就交给我们来处理传输!”“YES!(应用层)”“然后我们就可以把这些逻辑信息最终转化为物理信息送出去了!(网络接口层的诸位)”“(我)似乎还漏了负责路由器的几位……算了,他们太低调了,有空再介绍吧。”

“咳咳,这样传输的可是明文啊,你们不在乎数据被窃听复制篡改或者落到中间人的手里?”

“(我和其他人)SSL?什么中间人?”

“叫我TLS!算了,这不重要,你们想象一下这样的场景:一个不怀好意的第三方想要窃取用户数据,那么他会在路上伪装成目标网站服务器接收数据……”

“(我)第三方无法满足用户请求的,而且有独一无二的域名做保证……”

“笨蛋!域名系统是很不可靠的,域名欺骗域名劫持域名污染这些都是常有的事![3]还有,第三方完全可以先截取用户数据,再自己当客户端与目标网站建立连接,从目标网站抓取数据之后再转交给用户,这样用户就根本无法察觉自己被中间人攻击了!”

“(我)那你说该怎么办?(生气中)”

“首先,用户数据当然要被从头到尾都被加密了,而且要是强加密,否则分分钟被暴力破解;然后,需要有一个可靠的身份验证机制,保证用户和服务器之间没有第三方;还有,必须要保证一个数据包都不掉队,要知道为了建立加密连接我可是要帮客户端和目标服务器握手呢,这期间要是有数据包丢了而我却不知道,那就搞笑了!所以我要在TCP的帮助下工作(TCP:OK,建立可靠连接,我最擅长了!)最后就是,客户端和目标服务器各自持有不能被第三方截取到的密钥,要不然加密就失去意义了。”

“(我)那么,双方事先准备一对密钥?”

“不现实。鬼才知道用户想要和哪些网站建立HTTPS连接,怎么个事先准备法?又该用什么途径把密钥送到用户手里?网站服务器要是一直都用一个密钥,那么在不知情的情况下被第三方偷走了怎么办?那样后果会相当严重的!必须做到每个连接两个独一无二的密钥!”

“(我)等一下,两个?两个不同的密钥?”

“没错。如果是相同的密钥(采用对称加密,例如你用7zip加密了压缩包,密码设置为123456,那下次打开压缩包解密时也是输入123456,加密密钥和解密密钥是同一个),那么怎么秘密传递密钥就又是一个无解的问题了。你总不能线下交给用户吧(笑),如果加密传递,那么就变成一个先有鸡还是先有蛋的问题了:加密传递时的解密密钥又该如何安全传送?那么只能采用非对称加密了,加密密钥(公钥)是明文传递的,解密密钥(私钥)是秘密的,这样第三方只能干瞪眼。不过如果第三方伪装成目标服务器,那么他还是有办法对付非对称加密的,所以还需要可靠的身份验证机制。”

“(我)那么你的想法具体是怎样的呢?”

“说来话长,我的想法并不是那么容易理解的,下次再具体说明吧。”
“(我)好吧,TLS,下次就是你的专场了(笑)。对了,你有一个缺点,介意我提出来吗?”

“说吧,幽灵。”
“(我)拜托你能不能改掉这个不打招呼就冷不丁插话的坏毛病!(咆哮)”

下一篇,TLS的专场!

最后照例附上科普文链接集合:https://plus.google.com/u/0/109790703964908675921/about

参考资料:
1,TCP/IP协议族https://zh.wikipedia.org/zh/TCP/IP%E5%8D%8F%E8%AE%AE%E6%97%8F
2,OSI七层网络模型与TCP/IP四层网络模型
http://www.netboy365.com/article.asp?id=838
3,扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”https://plus.google.com/109790703964908675921/posts/aX22pV3242N

原文:https://plus.google.com/109790703964908675921/posts/Ask45LvmTF7

===========

SSL/TLS的原理以及互联网究竟是如何工作的(3)——TLS的专场!

话说上回[1]我向TLS承诺了这是他的专场,那么现在主角已经来了:

我:hi,TLS!这次是你的专场哦!

TLS:OK,那我就开始了!首先,我的大名叫做Transport Layer Security Protocol(传输层安全协议),是SSL的升级版。实际上我的左手和右手都是能用的,左手叫Record Layer(记录层),右手叫Handshake Layer(握手层)[2]……

我:喂喂,等一下,记录层?握手层?这都是什么啊?

TLS:别打断我!听我慢慢解释:TLS是基于TCP的可靠连接,而想要建立一个可靠连接就必须有一个被称为握手的过程,TCP就有啊[3](TCP:没错,我建立连接时就要经历three-way handshake(三路握手)的,这具体过程是……)

我&TLS:STOP!TCP,有空会给你开个专场的,现在你先暂时回去工作吧!(TCP:OK,说定了哦!)

TLS:继续吧,TCP有握手过程,那么我也一样,你也可以把我的握手过程看成是在TCP握手过程基础之上的改进。

开始说具体过程了!

首先,客户端向服务器端发送一个message,名叫”client hello”,包括SSL/TLS协议的版本号,客户端生成的随机数(P1,P指Parameter,参数)以及客户端支持的加密算法;

然后,服务器端发送另一个message,名叫”server hello”,确认所使用的加密算法以及生成并发送另一个随机数(P2),特别注意还有服务器端的数字证书[4]呢……

我:等一下,数字证书?为什么会这么早就出现了?

TLS:我说,你是怎么想的?难道你认为要连接建立开始传输用户数据之后才进行基于数字证书的身份认证吗?

我:为什么不行呢?先完成握手,建立连接,然后马上进行身份认证,似乎也不晚呢……

TLS:你!真!是!个!大!笨!蛋!连接建立之后首先一定是客户端数据被发送过去的,在浏览网页的情况下就是GET请求的HTTP数据包,如果不在此之前进行身份认证,那么这个数据包很可能会落到冒充目标网站服务器的第三方手里(也就是所谓的中间人攻击)!而你还没有任何办法!

我:就一个GET数据包,好像也不会怎么样……

TLS:I 服了 YOU!你知道网站的自动登录功能是怎么实现的吗?是cookie的功劳!第一次登陆成功之后你的用户名和密码就被储存在了cookie里,再次登录时浏览器就会在一开始的GET数据包中加入这个cookie,准确来说是加入数据包头部(HTTP Headers),cookie本身就是一种特殊的HTTP headers!在一开始用户名和密码就发过去了,那么传回来的就是登录之后的界面了,这就是自动登录的奥秘!

我:啊,我明白了!如果是启用了自动登录的网站被中间人攻击了,那么一旦不能在第一个用户数据包被传输之前发现这一点,那么用户账户就直接落到第三方手里了!先不说cookie的加密根本就不强,其实第三方都不需要破解加密的,只要直接利用手里的cookie就能完成登录从而为所欲为了!

TLS:没错,就是这样!所以身份认证过程一定要在握手阶段就完成!
接着说吧:
身份认证可以是双向的,也就是说服务器端也可以向客户端请求证书,认证过程也是类似的,简单来说就是对比签名和私钥还有主机名等,一般情况下这个匹配过程是很严格的,第三方的伪造证书很难过关。顺便说一句,身份认证时使用的算法和最终加密时使用的算法很多时候是同一个。对于浏览器,他自己信任着和不信任着一套证书,IE和chrome依据操作系统自带的证书系统,firefox则有着自己的一套证书系统。这些证书都是由可信赖的第三方证书颁发机构(Certficate Authority)颁发的,一般情况下没问题,除了一个大流氓之外……

我:哪个大流氓?啊,想起来了,以前好像听你说过,CNNIC(中国互联网信息中心)[5],不过到底是怎么回事啊?

TLS:这次我没空解释,下次我在说明中间人攻击的具体过程时就会好好说明的。先继续吧:

身份认证没有问题之后,客户端就会再生成一个随机数(P3),并用数字证书上的公钥进行加密之后再传输给服务器端。这里采用的是非对称加密算法,就以G+为例吧:”并使用ECDHE_ECDSA作为密钥交换机制“,这个ECDHE_ECDSA就是一种公钥算法(又叫做非对称算法),加密公钥是公开的,解密私钥是秘密的,所以第三方无法得知P3的值。服务器端收到之后就用自己的私钥解密得到P3,然后发送message通知客户端自己收到了。
接下来,服务器和客户端根据约定的加密算法,同时用手中的P1,P2和P3算出秘密的session key(会话金钥),一般情况下是128位或者256位,然后客户端再用这个金钥加密以后所有需要传输的用户数据再进行传输。这里有必要提一下,此时的传输单元被称作socket(套接字)[6],应用层协议(如HTTP)先处理好数据,再被完全加密(包括头部),再被注入到套接字中[7],这些套接字除了源地址和目的地址还有必要的完整性验证机制以及其他保证可靠性所需要的数据之外其他一切都是被强加密的。SSL(Secure Socket Layer,安全套接字层)的名字也是这么来的。

以上就是握手的全过程,握手层完成握手之后就是记录层在TCP的帮助之下负责传输了,请注意握手时采用的密钥交换算法和传输时采用的数据加密算法不是同一个,传输时的数据加密算法是对称加密算法[2],密钥就是通过握手最终算出来的那个会话金钥,以G+为例,这个算法就是CHACHA20_POLY1305。

我:(头昏眼花)真的很复杂啊……

TLS:晕死,你看到那份100多页的RFC[2](Request For Comment,请求评价文档)大概会跳楼吧!算了,直接上图吧!

我:谢谢啊(笑)。

TLS:关于中间人攻击,可是有很多好说的呢,下次还是我的专场啊!

我:OK!对了,听说goagent的安全性不好,这和他的那个证书goagentCA有关系吧?

TLS:没错!事实上那个证书是一个恐怖的存在!具体到时候再说吧!

你可以先看看这篇文章。[8]

下一篇,middle man,middle man,middle man,MITM!

最后照例附上科普文链接集合:https://plus.google.com/u/0/109790703964908675921/about

参考资料:
1,SSL/TLS的原理以及互联网究竟是如何工作的(2)
                                                    ————“更合适的架构,大家一起努力!”
https://plus.google.com/109790703964908675921/posts/Ask45LvmTF7
2,The Transport Layer Security (TLS) Protocol Version 1.2
http://tools.ietf.org/html/rfc5246
3,Transmission Control Protocol
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
4,数字证书及 CA 的扫盲介绍
http://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html
5,CNNIC 干过的那些破事儿
http://program-think.blogspot.com/2010/02/about-cnnic.html
6,基于 Socket 的网络编程技术及其实现
http://wenku.baidu.com/view/995639641ed9ad51f01df266.html?re=view
7,Secure Socket Layer
http://www.proceedings.informingscience.org/IS2002Proceedings/papers/Bhiog058Secur.pdf
8,翻墙软件 GoAgent 的安全风险https://plus.google.com/109790703964908675921/posts/eEt8YT9ryG3

原文:https://plus.google.com/109790703964908675921/posts/NwWoGQ9mcD

===========

SSL/TLS的原理以及互联网究竟是如何工作的(4)
                                                        ————中间人攻击,当心!
我:话说上次请TLS老兄来讲述了TLS协议到底是怎么一回事,最后提到了中间人攻击,那么……

TLS:别废话了,现在开始!首先我想要进行补充,我还有一个兄弟叫做DTLS(数据报传输层安全协议)[1],他是基于不可靠的UDP协议工作的,成功结合了TCP和UDP的优点,但是更加复杂,具体原理是……

我:T!L!S!你能别跑题吗?上次你讲的那么高深莫测,很多人都听得晕晕乎乎的呢,这次又想介绍一个更复杂的?STOP!上次说好这次讲述中间人攻击原理的!还有,不要打断我的话!

TLS:我说,我已经说得尽可能浅显了,要知道计算机领域的很多概念根本就无法类比到现实生活中去,如果硬要进行类比会严重扭曲原意的,所以我只能平铺直叙了。再说了,比起那一百多页的RFC文档[2],我已经说得很简单了好吧?

我:你能别提那份文档了吗?我花了半个晚上才勉强啃了30页,后来实在是坚持不下去了,吐血级体验啊!行了,言归正传吧,能开始说中间人攻击了吗?

TLS:OK!上次聊我的原理[3]的时候我特别强调了一定要有服务端身份验证过程(客户端身份验证过程是可选的,可有可无),那么为什么一定要有这一过程呢?

其实很简单,假设没有这一过程,那么一个恶意的第三方就可以在握手时截取通信数据,对于用户,假装成服务器;对于服务器,假装成用户。当第三方成功插入用户和服务器之间时,加密就形同虚设了,第三方可以轻易解密所有通信数据,此时解密密钥在第三方手里呢:第三方先假装成服务器与客户端完成handshake,拿到会话金钥,同时假装成客户端与服务器完成handshake,就像一个代理服务器一样代理了所有通信数据,而且客户端还根本察觉不到第三方的存在,看起来通信过程是正常的。[4]

我:那么第三方要怎样才能插入用户和服务器之间呢?

TLS:方法太多了:

首先你的数据要经过N个路由器的中转才能到达目标网站服务器,第三方随便就能伪装成路由器或者直接在路由器上做手脚将你的数据导向他们的陷阱服务器,局域网的网关也一样[5];
还有就是在DNS上动手脚了:例如你要连接到www.github.com,如果用的是天朝流氓ISP的域名解析服务器,那些走狗ISP们完全可以将域名解析服务器上github网站域名对应的IP地址给篡改为共匪的陷阱服务器的IP地址,会发生什么就不用我说了;就算你使用国外的域名解析服务器,当域名解析请求跨越GFW时GFW马上会知道你要干嘛,然后抢在那个域名解析服务器响应之前伪造域名解析结果并发送回来,然后也不用我说了。[6]
对了,提到这一点,顺便说一下GFW这半年来的“壮举”[7]:

1,2013-01-25 大规模中间人攻击 GitHub 网站
2,2014-09-01 大规模中间人攻击 Google 网站
3,2014-10 部分 IPv6 隧道服务器中间人攻击 Google 网站
4, 2014-09-30 大规模中间人攻击 Yahoo 网站
5,2014-10-02 大规模中间人攻击 Microsoft 网站
6,2014-10-08 部分教育网 IPv6 和隧道服务器中间人攻击 Facebook 网站
7, 2014-10-18 大规模中间人攻击 Apple iCloud 网站

(咳咳,第一次已经是将近两年前了)

我:天啊!对了,GFW是怎么对付基于证书的身份认证机制的呢?

TLS:伪造证书啊!这道理就跟用假身份证去冒充别人是一样的啊!不过基于数字证书的身份认证机制是极为严格的,认证时要比对拥有者·颁发者·有效期·主机名·公钥这些信息,一旦发现符合这些情况就会中止连接:[8]

1,根证书不被客户端所信任(准确来说有两种情况:1,目标网站直接采取根证书作为身份证明,客户端发现这一根证书不在信任列表当中,就会拒绝连接;2,目标网站的证书是被某个根证书所信任的,客户端发现这一证书本身和它所对应的根证书都不在信任列表当中,就会拒绝连接。证书之间的信任关系是怎么回事呢?具体看这里[9])
2,证书本身已经无效了(拥有者·颁发者·有效期·主机名·公钥这些信息至少其中之一对不上)
3,证书的common name (CN)无法匹配上Domain Name Server

这么说吧,基本上没有哪个第三方能过得了证书认证这一关的,但这一关最薄弱的环节其实是……你猜!

我:我上哪知道去?嗯,客户端?

TLS:接近了,准确来说有两个环节很薄弱:浏览器和用户。浏览器本身的认证机制要是出问题了,那么身份认证就完全废了。三大主流浏览器(firefox,chrome,IE)倒是一直都做得不错,但那些国产浏览器,哈哈,你懂的!尤其是360浏览器,还自吹“安全”呢,结果随便一个自签发的证书就把这货耍得团团转![10]

还有一个薄弱环节就是用户了,这也是最薄弱的环节:很多用户(尤其是小白用户)都根本不知道浏览器弹出的“目标网站证书有问题,是否继续连接?”这一提示意味着什么,通常都会直接选择继续,然后……那个恶意的证书就被添加到信任列表里了,也就是说攻击者下次还是能攻击成功的,而且再也没有提示了。如果是恶意的根证书,那就更糟糕了:攻击者得逞之后可以继续制作一堆不同网站的证书,这些证书都是被那个恶意根证书所信任的,那么用户下次就会被毫无察觉的中间人攻击了(因为那个恶意的根证书被信任了,那么那些被恶意根证书信任的证书也被浏览器自动信任了,即使是把那些证书放到不信任列表之中都没有用!)

我:看来一旦根证书出问题,后果会相当严重。

TLS:没错。那些小白用户使得基于证书的身份认证机制几乎废掉了,但除此之外,网站根本没有其他更好的选择:其他身份认证机制还有很多,但要么用户不友好,要么不适合网站这种几乎面对着无限的不知道身份的用户的情况,所以还是得继续使用基于证书的身份认证机制(我有空会介绍其他的身份认证机制的)。

所以浏览器们吸取教训了,现在三大主流浏览器在碰到自签发的证书时都不允许用户继续连接了,而且由原先的弹出窗口变成了全屏警告,强制用户看完相关警告信息。(当然,国产浏览器除外)

我:我记得这些年天朝自己颁发了一堆证书,而且最早那个CNNIC Root被firefox默认信任之后还引发了一场大争论……

TLS:Mozilla和微软都是混蛋!他们根本就不明白,默认信任了CNNIC Root意味着什么!看看这半年GFW疯狂发起的中间人攻击吧!

GFW只要制作一堆被CNNIC Root信任的伪造证书,就可以对任意HTTPS网站发起中间人攻击,而且大部分人都察觉不到!大部分人都不会去修改默认的证书信任列表,那么被CNNIC Root所信任的伪造证书就会自动被浏览器信任!同样道理,其他所有天朝共匪证书都是不能信的(包括那个12306的自签发根证书,根证书还不肯去CA申请一个,一定要自签发,明摆着有鬼!还有那些网银证书也是,去申请一个证书能花几个钱啊?怎么一个个都自签发呢?[11])!

我:看来现状很糟糕啊。

TLS:是啊。不过好在有人特别制作了自动除去所有共匪证书的程序,看这里[12]。对了,中间人攻击并不是只有伪造证书这一种的,还有一些更高级的,例如利用漏洞强制把HTTPS连接变成HTTP[8],以及强制把TLS降级为古老的SSL3.0再进行攻击的Poodle Attack[13]。就在今年4月的时候OPENSSL还爆出了迄今为止最大的漏洞呢:“心脏出血”[14]。这个漏洞是心跳协议扩展的漏洞,而要聊心跳协议就一定要和DTLS放在一起聊,所以我一开始才想介绍DTLS的……

我:STOP!下次再聊吧!

TLS:OK!下次还是……

我:我说TLS,你能给其他协议们出场机会吗?

TLS:(愤怒)OK!随你便!反正以后上HTTPS网站时,不要忘了是谁在保护你!

最后照例附上科普文链接集合:https://plus.google.com/u/0/109790703964908675921/about

参考资料:
1,Datagram Transport Layer Security
http://robin-seggelmann.de/papers/dtls.pdf
2,The Transport Layer Security (TLS) Protocol
https://tools.ietf.org/html/rfc5246
3,SSL/TLS的原理以及互联网究竟是如何工作的(3)
                                    ————TLS的专场!
https://plus.google.com/109790703964908675921/posts/NwWoGQ9mcDY
4,SSLTLS Session-Aware User Authentication—Or How to Effectively Thwart the Man-in-the-Middle
http://www-oldurls.inf.ethz.ch/personal/basin/pubs/mitm-cc.pdf
5,man-in-the-middle attack to the httPs Protocol
http://www.researchgate.net/publication/220496617_Man-in-the-Middle_Attack_to_the_HTTPS_Protocol/file/e0b495231a356171f5.pdf
6,扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”https://plus.google.com/109790703964908675921/posts/aX22pV3242N
7,GFW伪造证书大集合https://github.com/chengr28/RevokeChinaCerts/wiki/ReadMe(Chinese_Simplified)
8,On the security of SSLTLS-enabled applications
http://www.sciencedirect.com/science/article/pii/S2210832714000039
9,数字证书及CA的扫盲介绍https://plus.google.com/109790703964908675921/posts/3o9x3fpN2CB
10,国产流氓软件恶事专辑https://plus.google.com/109790703964908675921/posts/Y6n7hWvUNc1
11,天朝颁发的证书一览表https://plus.google.com/109790703964908675921/posts/GHaH3ciZMzd
12,强力推荐把共匪数字证书轰出去的程序:RevokeChinaCertshttps://plus.google.com/109790703964908675921/posts/TzsdGi9NZQw
13,最新版TORBrowser,Poodle 攻击与前置代理推荐之shadowsockshttps://plus.google.com/109790703964908675921/posts/YnvBLAd6SQ1
14,http://program-think.blogspot.de/2014/04/openssl-heartbleed.html

原文:https://plus.google.com/109790703964908675921/posts/3U3iMGDNZiB

===========

SSL/TLS的原理以及互联网究竟是如何工作的(5) ——DNS和他的兄弟

我:话说上次好不容易送走了TLS,这次……

DNS:(突然蹦出来)这次当然是我的专场啦!大家好,我叫DNS(Domain Name System,域名系统),我出生于1987年[1],在我出生之前计算机科学家们是用hosts.txt文件解决主机名与对应IP地址的对应问题的,但随着互联网中主机数量的增长,hosts文件变得越来越臃肿,也越来越用户不友好,我就横空出世啦!(不过各操作系统中的hosts文件依旧保留至今,历史的遗迹啊)

我主要工作在UDP/IP协议之上,实质是一个分布式的公开数据库系统,存储着各网站域名和IP地址对应的数据,又称作RRsets(Resourse Record,资源记录集合),这里面域名和对应IP地址形成了映射……

我:D!N!S!为什么你们这些协议都有着爱打断别人的话的毛病啊?还有,你不必在这叽里呱啦了,我已经让你出场过两次了![2][3]

DNS:不行,我这次还就不走了,因为:1,你在这[3]大肆嘲笑我,说我傻乎乎的工作在不可靠无连接的UDP之上从而让GFW很轻易的就能钻空子;2,我有一个兄弟你没有提到,今天我一定要把他介绍给大家,让大家看看我们DNS家族没有你想象的那么弱不经风!

我:关于第一点,我想我说的一点都没错:你工作在不可靠的UDP之上,没有任何安全机制,的确是很傻啊:)

DNS:难道你就没有想过我为什么主要工作在UDP之上呢?

我:很简单,因为面向连接的TCP工作时需要经历复杂的建立连接和拆除连接的过程,建立一条逻辑上的“专线”(Virtual circuit,虚电路[4],或者直接叫做Connection)以保证数据传输的可靠性,而UDP就没有这些工作步骤了,只管发送不管到达。而你这个懒鬼不肯经历TCP那些麻烦的工作步骤,所以就选择了UDP啊……

DNS:住口!我才不是什么懒鬼呢!你想过没有,TCP那复杂的连接建立与拆除过程是要消耗相当数量的资源的? 你想过没有,每一个Resolver(域名解析服务器,负责和客户端通信)和Name Server(域名权威服务器,储存有RRsets,负责和Resolver通信)每天都要面对着极大量的查询请求[1]?你想过没有,域名解析是一个非常短暂的过程,如果采用TCP,那么很多时候连接建立和拆除的过程都比查询过程要长!

我:……如果采用TCP,那么每一个相关的服务器消耗的计算资源都会疯涨,而1987年服务器的计算能力怕是连今天的PC都赶不上,再加上连接建立与拆除的时间,用户体验会变得极为糟糕的,服务器维护成本也会暴增……OK,我明白了,对不起,DNS。

DNS:你明白就好。说起来,我没有任何安全机制很大程度上也是因为性能。不过我的创造者们也的确太欠考虑了,我在互联网中是极为关键的一环,没有任何安全机制的确是说不过去,所以我这回把我的兄弟DNSSEC叫来了。

我:DNSSEC?DNS Security Extension Protocol(DNS安全扩展协议)?
DNSSEC:正是本人。我出生于1999年[5],可惜迄今为止还是没有被大规模部署,懒惰的人类啊,一个个拖延症都那么重!

我:(汗)哈哈,是的,不过言归正传吧,上次我在这里[3]就提到了几条应对针对DNS的攻击的思路,你实现了几条呢?

DNSSEC:让我看看……我添加了身份认证机制,还有就是端到端的完整性校验了,我没有加密,也没有基于TCP工作……

我:添加了身份认证机制?这样倒是可以使GFW伪造查询结果的手段失效了,可是如果说没有加密的话,还是无法防止真正的查询结果被篡改啊……

DNSSEC:不,我可以防止真正的查询结果被篡改的!

我:怎么说?

DNSSEC:重点在于我实现了“端到端的完整性校验”,听说过数字签名[6]吗?我就是利用了数字签名的机制进行完整性校验的,从而保证了服务器传回的查询结果没有被篡改。[7]
我:我不清楚“端到端”是什么意思。

DNSSEC:所谓的“端到端(end-to-end)”是和“跳板到跳板(hop-to-hop)”对应的,hop-to-hop是指这样一种机制:在计算机网络中一个路由器p收到了一条分组(massage)m,p可以确定分组m的确来自于合法通信方路由器q,而且m既没有被篡改也不是被攻击者重放的旧消息[8](有空我会介绍一下重放攻击);p和q都是负责存储转发的路由器,起到了信息跳板的作用,所以叫做“跳板到跳板”。

而end-to-end则是指客户端可以确认收到的分组的确是来自于目标服务器的,没有被篡改也不是重放的消息;客户端和目标服务器都是通信终端,所以被称作“端到端”。
我:这样啊。我看了一下,数字签名和散列值是用来进行文件完整性校验的,也能用于查询结果啊?

DNSSEC:当然可以啦!我的身份认证机制也是通过数字签名实现的,GFW可出示不了等价的有效数字签名呢!包括在进行缓存动态更新的时候,我也可以通过同样的机制来防止缓存投毒!

我:听起来不错,但你能对付流氓ISP的DNS劫持吗?

DNSSEC:这……我对付不了,因为DNS是公开的分布式数据库……

我:“公开的”意思就是没有权限限制[9],任何人都能查看修改数据是吧!好吧,这一点都不奇怪。不过如果服务器本身就不靠谱,那么其他安全机制再完善都没用了。

DNSSEC:不是这样的!没有权限限制和随便什么人都能查看修改数据可不是一回事!我的意思是,我可以通过检验缓存中的RRsets的数字签名来确认服务器缓存是否被投毒了,但这前提是服务器已经运行了一段时间了!第一次运行的时候,我可没地方去比对数字签名![9]

我:看来你离完美很远呢……

DNSSEC:这个世界上没有完美!

我:我知道,但你为什么不加密呢?就你这样,虽说GFW无法玩伪造和篡改的花招了,但用户请求内容还是被GFW知道了啊!

DNSSEC:这我也没办法,当初我的设计者出于性能考虑放弃了加密了,而且也没让我工作在TCP之上。

我:真的应该好好改造你!我还以为以不靠谱著称的DNS家族终于有了一个例外呢,原来还是个水货!行了,你们DNS家族的出场机会用光了,回应用层工作室去吧!

TLS:下次是不是应该讲讲我的兄弟DTLS了?

我:对不起,不行!下次是IP的专场!
(IP:终于想起我来了,感动啊!)

最后附上科普文链接集合:https://plus.google.com/u/0/109790703964908675921/about

参考资料:
1,Domain Names – Concepts and Facilities
https://tools.ietf.org/html/rfc1034
2,扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”https://plus.google.com/109790703964908675921/posts/aX22pV3242N
3,GFW的工作原理(2)
                                 ————不靠谱的DNS,总是被钻空子
https://plus.google.com/109790703964908675921/posts/Wqz2qrXdyqs
4,Virtual circuit
https://en.wikipedia.org/wiki/Virtual_circuit
5,Domain Name System Security Extensions
https://www.ietf.org/rfc/rfc2535.txt
6,http://program-think.blogspot.com/2013/02/file-integrity-check.html
7,http://compsec101.antibozo.net/papers/dnssec/dnssec.html
8,Hop Integrity in Computer Networks
http://www.crsr.net/files/jsac1.pdf
9,Threat Analysis of the Domain Name System (DNS)
http://www.ietf.org/rfc/rfc3833.txt

原文:https://plus.google.com/109790703964908675921/posts/8KX9pDDjQxq

===========

SSL/TLS的原理以及互联网究竟是如何工作的(6) ——嘿,我是IP!

我:好久都没有来这里了,也不知那些协议朋友们过得怎么样了。说起来,最近有一条消息火了:“今天在Q群里听到一个做云服务的群友说国家刚下的通知,以后家庭宽带只能接内网IP了,也就是说拨号上网拨到的不再是公网IP地址还是10开头的内网IP地址,先从直辖市开始到4月底全国完成转变,文件说是防止利用家庭宽带搭建违法网站,红头文件,消息来源可靠。”[1]

IP:哈哈,是你啊!好久没来了呢!……你怎么一脸的不高兴?

我:天朝网络就要变成完全的局域网了,到时我就无法翻墙了,我怎么高兴的起来啊!

IP:怎么回事啊?……我刚刚听到你自言自语的那条消息了,你是指这个?NAT?

我:什么NAT……以后众屁民上网的时候就没有公网IP,只有内网IP了!这样我还怎么翻墙啊!

IP:……你知道什么是内网IP吗?你知道NAT是怎么回事吗?

我:我不知道,反正对翻墙党来说肯定不是好事……

IP:闭嘴!你根本就什么都不知道,还自己在那里意淫!哼,刚好我现在有空,就好好给你科普科普吧!

我:到底是怎么回事?

IP:好好听着!要把这事情说清楚,得从我自己说起。本人是大名鼎鼎的IP(Internet Protocol,互联网协议),工作在网络层,是互联网的核心协议之一,也可以说是最重要的一个协议。我提供的是不可靠的“Best-Effort”服务,也就是说我不保证packet能被送达到目的地,如果你想要可靠连接,那就得请传输层的TCP帮忙了。

IP地址应该知道吧?我可以为两个间接连接的设备传输数据:我先给他们分配IP地址(公网上的IP地址是独一无二不可重复的,否则就找不到目的地了),可以手动分配,也可以通过DHCP[2](Dynamic Host Configuration Protocol,动态主机设置协议)自动分配。至于这个DHCP吗,他是……

我:停!别跑题成吗,IP同学?

IP:好吧!这次就算了,下次我一定会拉着你说个够!分配了IP地址之后,其中一方就可以发起连接了,另一方则是被动监听连接并最终建立连接。不过很显然你不能幻想直接走一条专线把packet送到目的地,那么这繁忙的交通应该由谁来指挥呢?packet的路径又该怎么选择呢?

我:我听说过一点,路由器[3]吗?

IP:答对了!路由器就是负责存储转发packet的重要存在!不过今天这话题的重点不在路由器上,这里就不扯开了,不过按照规范路由器是不能去把packet头部的公网IP换成内网IP的。NAT实质上是一种破坏互联网的行为。

我:什么公网内网啊,越来越糊涂了……

IP:说起来,其实不应该存在什么内网的:所有的主机都由唯一的IP地址标定,这不是应该的吗?可事实却不是如此,因为IPv4地址已经在4年前耗尽了![4]互联网的成长速度大大超出了当初设计协议的互联网先贤们的想象!

说一下到底是怎么回事吧:我有两个版本,版本4和版本6,也就是所谓的IPv4和IPv6。第一个版本诞生于1981年(相当早吧?),由RFC791定义[5],被全球性采用。第二个版本诞生于1996年,由RFC1883定义[6],迄今为止还没有被大规模部署。事实上,截至去年年底,超过94%的互联网通信还是依赖着IPv4呢[6]。

IPv4定义的IP地址是32位的,也就是说总共能够唯一性标定2^32个互联网设备(不仅仅是客户端服务器他们,路由器这些也是有自己的IP地址的)。而IPv6定义的IP地址是128位的,那么就能唯一性标定2^128个互联网设备了。

听起来2^32已经是个很大的数据了,可是事实证明这些IP地址根本就不够用!可是从IPv4转换到IPv6需要软件和硬件的支持,成本很高,很多公司和ISP根本就不愿出钱,但也不能不提供网络服务啊!还有那么多人想要接入互联网呢,怎么办啊?

那么,解决方法就来了:NAT[7](Network Address Translation,网络地址转换)!直接接入公网的设备自然是需要一个唯一的IP地址,但我们可以这样:比方说有A和B两个小区,每个小区都有50个用户,现在他们要接入互联网;如果直接接入公网,自然需要总共一百个公网IP地址,但ISP提供不了这么多地址,那么就想了一个巧妙的主意:这两个小区各自都可以看成一个独立的局域网(内网[8]),然后给小区里的用户分配内网专用IP地址(10.0.0.0/8192.168.0.0/16,后者比较常见)。在一个内网里,内网IP要唯一性标定里面的设备,但不同的内网是可以发生IP地址重合的,因为在公网上的设备看来,没有被内网IP所标定的设备……

好吧,这里有点不好理解,这么说吧,小区A或B对外表现的就像是一台设备:小区里的一个用户发起了连接,在经过NAT box的时候,内网IP被转换成了公网IP(IP packet的头部被重写了),然后被送出去最终到达目的地。不同的用户,转换的公网IP都是一样的(静态NAT不是这样,静态NAT会把同时连接的不同用户的内网IP转换为不同的公网IP,所以客户端还是可以被动监听建立连接的),端口是不同的(但端口并不是设备判断身份的标准,所以公网的设备还是会把小区里的用户都当成同一个人的)。

这样一来,100个IP地址请求就被压缩成两个IP地址了,终于可以解决燃眉之急啦!

可是新问题来了:事实上小区里的用户并没有真正拥有一个IP地址,在互联网上没有真正属于自己的位置,而服务器是需要有一个属于自己的位置的。也就是说,小区里所有的用户都无法成为服务器了(关键在于没有唯一的公网IP,无法被动监听建立连接。想想看,50个用户在外人看起来就是一个人,那么你怎么发起通向其中某个人的连接呢?):自己搭建服务器开网站是别想指望了,P2P也不行了(P2P的实质就是每个用户既是客户端又是服务器端,现在没办法当服务器端了 ,还谈什么P2P?)。

当然,翻墙是不会有问题的,因为翻墙的实质还是主动发起和国外服务器的连接,这是不会被NAT影响的。PS:但是Tor流量混淆插件中的flashproxy没法用了,因为使用时Tor客户端需要被动监听国外的flashproxy发起的连接,具体看这里吧[9]。

我:终于明白了。

IP:也就是说,朝廷这么做是想灭掉不受控制的个人网站和P2P,跟翻墙没什么关系。但也不是没有办法:通过端口转发还是可以实现被动监听连接的,不过这事说起来又复杂了,我也没有看多少资料,等我研究出结果之后就会找你的。

我:谢谢啊,IP!

IP:(笑)举手之劳。不过,请记住一点:以后不要听风就是雨,什么都不清楚就开始意淫!

我:遵命!啊,还有一点,有没有可能把整个天朝都变成内网?

IP:别忘了NAT不影响翻墙,把整个天朝都变成内网你也能翻出去,除非他们切断了海底光缆:)

我:等一下,既然在公网上的设备看来小区用户都是同一个人,那么网站的数据该怎么传回呢?

IP:静态NAT的话很好理解吧?至于多对一的NAT,NAT box是通过端口区分谁是谁的,在内部专门放置了一张table进行映射。有一点需要注意:在不主动发起连接的情况下,客户端是根本就没有公网IP的(所以前面我才说客户端其实没有真正成为互联网的一部分),那么自然无法当服务器了(别人要通过公网IP才能找到你,可以重复的内网IP可没法用来找人啊)。

科普文链接集合:https://plus.google.com/109790703964908675921/posts/TpdEExwyrVj

参考资料:
1,大局域网模式正在形成https://plus.google.com/u/0/109790703964908675921/posts/aK72omWULj8?cfem=1
2,DHCP
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
3,GFW的工作原理(3)
                          ——IP封锁,最可恶的手段!
https://plus.google.com/109790703964908675921/posts/SJk5dtnpcdX
4,http://www.csdn.net/article/2011-04-15/295924
5,https://en.wikipedia.org/wiki/IPv4
6,https://en.wikipedia.org/wiki/IPv6
7,https://en.wikipedia.org/wiki/Network_address_translation
8,https://en.wikipedia.org/wiki/Private_network
9,TOR与GFW的PK(4)
                             ————“快来我这里,冲向自由世界!”
https://plus.google.com/109790703964908675921/posts/Lgyn83vovUy

原文:https://plus.google.com/109790703964908675921/posts/8GLWQxp5yJN

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s