Quantcast
Channel: GFW BLOG(功夫网与翻墙)
Viewing all 1645 articles
Browse latest View live

中国特供版Flash:死刑将至,何以再掀波澜

$
0
0


2017年7月26日,Adobe凌晨宣布,将于2020年停止开发和分发Flash浏览器插件,并且建议内容创作者将Flash内容移植到HTML5等格式。这基本宣布了Flash 的死刑,其实早在之前,Chome、Safari等主流浏览器就已经抛弃Flash。

特供版Flash 曝隐私问题

没想到,在正式宣布其"死刑"之后一年,Flash 在国内却以这样一种方式成为热议话题。Adobe 近期与国内一家公司达成合作,为国内用户提供特供版Flash,并且在其隐私声明中明确表示可能会收集用户信息,有意思的是在媒体曝光之后,很快该公司又重新修改了隐私声明。 

与Adobe在Flash player上达成合作的是重庆的一家名为重橙网络的公司。在隐私协议修改之后,精简了许多关于细节问题,只强调了在不侵犯用户隐私的前提下,可能会记录用户使用Flash Play的记录和相关数据,同时也去掉了关于将信息披露给第三方的细则。

而在这项合作达成之后,Flash Player加入了地区验证机制,安装海外版Flash 的用户在升级过程中如果检测到地区位于国内,则会提示"地区不相容,请重新安装",而原本Flash Player的插件更新地址https://get.adobe.com/cn/flashplayer ,会自动跳转到:https://www.flash.cn/。

微信截图_20180712175825.png

在Flash 中国官网下载在线安装包,目前最新版本号为 v30.0.0.134,包含FlashHelperService服务,默认运行在后台。从其服务描述中,"会像2144发送匿名使用数据以帮助改进Flash player",其中提到的2144是一家互联网公司,旗下有2144游戏中心,而重橙网络是其分公司。此前有用户反映,安装Flash Player过程中被捆绑安装2144游戏中心,但笔者在安装过程中并没有遇到。

无标题.0000000.png关于这个"特供版Flash"的一些异常行为,在六月底有网友@HorseLuke 发现Adobe Flash Player 存在乱弹窗行为,怀疑利用FlashHelperService服务完成。弹窗推荐新闻资讯,左上角还有小字显示"Flash助手推荐"。网友立即在Adobe官方论坛发帖反馈该问题,而客户在回复"Thanks for your feedback.  "之后也不再有回应。

截稿之时,我们还没有看到Adobe或者2144公司对外界的反应有任何回应。

安全问题导致Flash逐渐被遗弃

其实笔者觉得,这半年以来国内外数据隐私事件频发,FaceBook、twitter、腾讯、百度等大型互联网公司都有涉及,导致用户对数据隐私问题一直非常敏感。而恰好Flash Player在这个时间点出现,又一次被网友推上风口浪尖实属必然。但Flash长久以来存在的安全问题却是其走向末路的关键原因……

1231231231231231231231231231231231.jpg仅仅在FreeBuf上,就已经有大量关于介绍或者利用Flash漏洞的文章,也因此导致Office、Chrome等越来越多的主流软件开始远离Flash。另外,利用Flash Cookies来进行用户数据跟踪已经成为各大广告联盟推广普遍使用的手段,对于用户隐私来说也是一颗不定时炸弹。

为什么Flash却又没有彻底被摈弃

在HTML5出现之后,它基本能够实现Flash的所有功能,也让更多的人认识到Flash的落后、效率变低,或者说,这些问题也是催生HTML5迅速普及的必要因素。既然各大公司已经开始抛弃Flash,那我们完全放弃不就行了吗?

微信截图_20180712185719.png最早开始抵触Flash的就是苹果,从乔布斯时代开始,到YouTube开始摈弃Flash,目前国内爱奇艺、腾讯/优酷等主流视频网站也已经开始支持并默认使用HTML5,但却依然没有彻底摈弃。本身目前大部分视频网站依然没有实现较好的盈利,而放弃Flash 意味着可能放弃一部分用户,或者说被迫用户转向其他竞争对手网站。另外,广告也是支持Flash一直坚持到现在的重要原因,放弃Flash,并不能给他们带来利益上的好处。

这是CNCERT统计的2018年第一季度国内Windows系统以及PC端IE浏览器的分布情况,其中XP系统以及IE 8以下旧版本浏览器依然占据较大比重。这一部分用户几乎重度依赖Flash,或者用TK大佬的话来说"我们毕竟还是发展中国家,一些日常生活不得不访问的网站才刚刚解决了仅支持 IE6 的问题。 ​​​​"

大神支招避免使用特供版Flash

如果各位在看完这篇文章之后的确介意使用这个所谓特供版的Flash,那么安装海外版本或许可行,不然就只有彻底卸载Flash,大部分使用场景下还是没问题的。目前来看,只有特供版Flash应该只是从大版本 v30开始出现,所以安装之前的旧版本应该就可以,当然要注意屏蔽更新,而微软Edge 浏览器自带的Flash暂时不受影响。

微信截图_20180712141531.png

安装海外版Flash,TK大佬在微博上给出了方法,"打开区域和语言设置,改成中文(简体,新加坡),重启",就能够顺利安装上海外版本。这个方法网友可以自行测试,笔者在挂上梯子的情况下进入"https://get.adobe.com/cn/flashplayer"这个链接下载,发现并没有跳转中国版官网,并且可以顺利以原来的方式安装Flash Player,这种方法也仅供参考,很有可能随时挂掉。

最后,想说的是,离Flash 的官方死刑执行日期还有一年多的时间,希望在国内也能尽快完全摆脱对Flash的依赖。但是目前来看,在2020年能够彻底全面弃用Flash 已经很乐观了。2014年,Windows XP系统停止维护之后,腾讯、360等安全公司纷纷表示将支持维护2-3年,国外部分地区也由第三方公司继续维护一段时间。Adobe 或许也是想将Flash 交托给第三方公司持续维护,如果不是这次隐私问题被晒出来,或许绝大部分人都不知道Flash 已经不再那么单纯……


郑世鹏律师:当疫苗事件遇上删帖

$
0
0

假疫苗事件一触即发,引发了民众对注射疫苗的公共讨论。与此同时,我们看到,各种讨论的帖子一而再再而三地遭到了被删的命运。事情起因于山东被揭露假疫苗事情,之后又有网友揭露制造疫苗公司存在不少问题,之后把国家食品药品监督局某领导与十年前三鹿奶粉事件联系起来。事件的继续发酵,与十年前的三鹿奶粉事件,颇多相同之处。

十年前的三鹿奶粉事件,政府的做法引人诟病,至今民众还心存芥蒂。而今次假疫苗事件,疯狂删帖的背后,与十年前毫无异样,这说明了什么?为什么每一次公共事件开始都是民意汹涌澎湃,最后无一不是不了了之?

笔者认为,删帖的背后,需要讨论几个问题:第一,要不要让人说?第二,说得不好,要不要删帖?第三,公共危机,怎么办?

关于第一个问题:要不要让人说?笔者认为,要的。

所谓和谐,"和"字旁边是一"口"一"禾","谐"字旁边是"言"和"皆",这意思不是很明显吗,人人都有饭吃,有话说。这恐怕是和谐最基本之含义。

人类发展到一定程度,就会有表达的欲望和需求。民主的社会,对公共事件的讨论,无一不是提供条件以促进,以达到兼听则明,更好解决公关危机。只有听取多方面的意见,才能明辨是非。即使在古之中国,也不乏这方面的典型例子。如:

《管子·君臣上》:"夫民别而听之则愚,合而听之则圣。"《资治通鉴·唐太宗贞观二年》:"上(唐太宗)问魏徵曰:人主何为而明,何为而暗?对曰:兼听则明,偏信则暗。"

民主的社会,应当是自由表达的社会,兼听则明,偏信则暗,这最基本的道理,处于今时今日,恐怕无需赘述。要不要让人说,要的。

关于第二个问题:说得不好,要不要删帖?

人之表达,因为有背景、知识储备、智力认知等限制,总有盲点,无法保证人人之言说,都能达到客观公正的态度,即使是政府所制定的政策,也完全无法保证就是良策。政府尚且如此,何苛刻于民众?如果因为不公正不客观甚至是逆耳之言,就可以对其言论进行扼杀、删帖,则无异于文化沙文主义,无异于强权就是真理。

所谓的讨论,所谓的表达,以平等为前提。所谓的平等,就是你有你的话,我有我的话,各自表达,民众自行选择倾听。如果不平等,你有你的话,然后我却无法表达(被删帖),你说,你是赢了这次的公共讨论呢?你说你能让人心服口服?"别黑白而定一尊",可以理解,"独尊儒术"也没有意见,但是总不能"罢黜百家"呀。因为总有人喜欢百家,而非儒术。更何况,"天下一致而百虑,殊途而同归",甚至儒家先祖孔夫子还向老子请教呢。

所以,说得不好,要不要删帖?笔者认为,没必要。

关于第三个问题:对于公共危机,怎么办?

像今次假疫苗事件,对于网络上各种的讨论,引发公共危机,怎么办?

笔者认为,可以组织电视公开辩论。这不仅仅是普及公共知识,重建公信力,也是安定民心的不二办法。我们都知道,政府有足够的智囊团,可以组织政府与民间就此话题进行公共讨论,用证据说话,到底此疫苗是真的或者假的,为什么是真的或者假的,有关领导的亲戚小孩等是否注射此疫苗(商鞅当年刑公子虔之法,笔者认为此举可以安定人心),不合格的疫苗怎样处理?是否流入社会?之前发生的假疫苗事情,处理是否得当等等。

通过展开电视大辩论,用证据说话,理性客观讨论,公共危机自解,民众也不会引起恐慌。亦何须频频删帖,遮遮掩掩,欲盖弥彰,反而让民众嗤之以鼻。

言者无罪,闻者足戒,不应当成为领导的一个境界,而应当成为社会的基本共识。难道不是吗?​​​

2018 - 06/07 - 翻墙技术与大事记

轻松几步搭建 WireGuard (快速安全的下一代 VPN)

$
0
0

WireGuard 是一个快速安全的新型 VPN 隧道程序,它简单高效的特性特别适合在手机等低能耗设备上使用。

WireGuard 不同于 IPSec ,它的设计简单(目前整体只有几千行代码),在不使用的情况下默认不会传输任何 UDP 数据包,而且能够无缝漫游在不同的 IP 地址间,这些特定都使它特别适合于移动设备的使用。目前 WireGuard 基于 Linux 内核实现,得到了 Linux 内核主要维护者 Greg KH 的肯定。下面介绍如何在 Ubuntu 16.04 搭建使用 WireGuard 。

搭建步骤

下载安装 WireGuard (服务端和客户端都需要安装)

$ sudo add-apt-repository ppa:wireguard/wireguard
$ sudo apt-get update
$ sudo apt-get install wireguard

配置服务端相关参数,创建并编辑 /etc/wireguard/wg0.conf,内容如下:

[Interface]
PrivateKey = <Private Key>
Address = 10.0.0.1/24
ListenPort = 56660
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
SaveConfig = true

其中 PrivateKey通过命令 wg genkey生成。

启动服务端 WireGuard

$ wg-quick up wg0

可以通过命令 wg检查启动是否成功,成功的话会输出如下内容:

interface: wg0
public key: xxxxxxxxxx
private key: (hidden)
listening port: 56660

将 WireGuard 设置成开机启动

$ systemctl enable wg-quick@wg0

配置客户端相关参数,创建并编辑 /etc/wireguard/wg0.conf,内容如下:

[Interface]
PrivateKey = <Private Key>
Address = 10.0.0.3/24
DNS = 8.8.8.8

[Peer]
PublicKey = xxxxxxxxxx
Endpoint = <Server Public IP>:56660
AllowedIPs = 0.0.0.0/0

其中 PrivateKey也是通过命令 wg genkey生成, PeerPublicKey填入上面服务端 wg命令返回的 public keyEndpoint的 IP 设置为服务端可访问的公网 IP 。

启动客户端 WireGuard

$ wg-quick up wg0

启动后同样通过命令 wg可查看公钥。

在服务端添加客户端信息

$ sudo wg set wg0 peer <Public Key> allowed-ips 10.0.0.3/24

Public Key是客户端的公钥。
如果在服务端配置信息里设置了 SaveConfig = true那么刚才添加的客户端参数信息会在服务端关闭时自动保存到配置文件中。如果想立即存储刚设置的参数也可以执行命令 wg-quick save wg0

测试验证

完成上述步骤后客户端便能直接访问服务端所在的网络了,可以通过 ping 10.0.0.1进行验证。

Tips

  1. WireGuard 能够提供类似 TCP keepalive 的功能,如果客户端在 NAT 子网可以考虑开启这一选项
  2. WireGuard 目前仅实现了 Linux 内核模块版本,所以目前客户端仅支持部分 Linux 和 Android 。

用 dig 命令辨别 DNS 是否被污染

$
0
0
来源: https://kyle.ai/blog/6340.html

原理

既然说起 DNS 和其污染问题,就不得不先看看 DNS 系统是如何工作的,这个自从上个世纪80出现的方便大家连接主机的系统的确是有问题。从 Wikipedia 上偷张图先。
563px-An_example_of_theoretical_DNS_recursion.svg_
DNS 解析流程图
图中可以看到我们的 ISP 的 DNS 服务器在图中叫做 DNS Recurser,在解析一个域名的时候,总共经过了以下的步骤,图是以 www.wikipedia.org 作为示范的:
  1. 向 root 服务器获取该 gTLD 的管辖服务器,图中为 org 结尾的域名
  2. root 服务器返回 org 的管辖服务器
  3. 向 org 的管辖服务器查询,谁来负责解析 wikipedia.org 这个域名的
  4. org 的管辖服务器返回解析 wikipedia.org 的服务器 IP 地址
  5. 向 wikipedia.org 的解析服务器发出查询,解析 www.wikipedia.org 的 IP 地址
  6. 拿到最终要的 IP 地址
共6个步骤。那么如果在最后一次查询的时候,有人假冒了 wikipedia.org 的解析服务器,则可以在中间进行欺骗攻击,致使用户最后得到的 IP 地址不是真实的地址。如图所示,
563px-An_example_of_theoretical_DNS_recursion.svg_1
解析请求被劫持
更详细的关于 DNS 的内容,可以自行参考 rfc1035(http://tools.ietf.org/html/rfc1035)。

手工模拟

以上是大致的解析原理,我们手工一步一步来模拟解析的每个步骤吧。这里我用的环境是北京联通 ADSL + Mac OS X 10.7 『Lion』 + 某国家 VPN 一条。工具用到了 dig 和 tcpdump 来完成,Windows 下默认木有俩工具似乎,大家自行寻找吧,或者找一个 GNU/Linux 发行版装上,个人推荐 Ubuntu,有 red hat 情节的,就 Fedora 好了。首先用联通的 ADSL 来试验下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ dig//直接获取根服务器的地址
; <<>> DiG 9.8.3-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59858
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;.              IN  NS
;; ANSWER SECTION:
.           205043  IN  NS  e.root-servers.net.
.           205043  IN  NS  h.root-servers.net.
.           205043  IN  NS  l.root-servers.net.
.           205043  IN  NS  i.root-servers.net.
.           205043  IN  NS  a.root-servers.net.
.           205043  IN  NS  d.root-servers.net.
.           205043  IN  NS  c.root-servers.net.
.           205043  IN  NS  b.root-servers.net.
.           205043  IN  NS  j.root-servers.net.
.           205043  IN  NS  k.root-servers.net.
.           205043  IN  NS  g.root-servers.net.
.           205043  IN  NS  m.root-servers.net.
.           205043  IN  NS  f.root-servers.net.
;; ADDITIONAL SECTION:
k.root-servers.net. 604222  IN  AAAA    2001:7fd::1
m.root-servers.net. 602881  IN  A   202.12.27.33
f.root-servers.net. 604218  IN  AAAA    2001:500:2f::f
;; Query time: 11 msec
;; SERVER: 202.96.134.133#53(202.96.134.133)
;; WHEN: Wed Sep 27 15:56:19 2017
;; MSG SIZE  rcvd: 300
这里我们可以看到,全球的域名根服务器共有从 a 到 m,共 13 组服务器。继续去 dig 出来这些服务器的地址吧,随便找一个好了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ dige.root-servers.net
; <<>> DiG 9.8.3-P1 <<>> e.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25194
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;e.root-servers.net.        IN  A
;; ANSWER SECTION:
e.root-servers.net. 84796   IN  A   192.203.230.10
;; Query time: 4 msec
;; SERVER: 202.96.134.133#53(202.96.134.133)
;; WHEN: Wed Sep 27 15:56:51 2017
;; MSG SIZE  rcvd: 52
这里我们抓到了其中一组的 DNS 根服务器 e.root-servers.net 的地址为 192.203.230.10,继续
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
$ dig-t ns @192.203.230.10 com.
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.203.230.10 com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 691
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;com.               IN  NS
;; AUTHORITY SECTION:
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
m.gtld-servers.net. 172800  IN  A   192.55.83.30
a.gtld-servers.net. 172800  IN  AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN  AAAA    2001:503:231d::2:30
;; Query time: 349 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Wed Sep 27 15:57:39 2017
;; MSG SIZE  rcvd: 509
上面共有从 a 到 m,一样是 13 组服务器在所有的 com. 的 gTLD 的记录保存。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ dig-t ns @192.5.6.30 twitter.com
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.5.6.30 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21761
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; ANSWER SECTION:
twitter.com.        240 IN  A   78.16.49.15
;; Query time: 13 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 27 15:58:18 2017
;; MSG SIZE  rcvd: 45
这里看到问题了么?本来应该返回 twitter.com 的具体的解析服务器,为什么直接返回了一个 A 记录?而且还是这么诡异的一个地址?查询以下这个 IP 的归属地,是『新西兰 奥克兰Telstraclear公司』,应该是胡乱编出来的地址了。至此再测试下去意义也就不大了,具体原因等会儿分析。换上 VPN 看看结果如何
1
2
3
4
5
6
7
8
9
10
11
12
13
$ dig
# 这里的结果完全一样,我们继续选择 e 的那组
$ dige.root-servers.net
# 嗯,这里也一样,继续
$ dig-t ns @192.203.230.10 com.
# 没有什么新奇的,继续…
以上几条结果都是一样的返回
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ dig-t ns @192.5.6.30 twitter.com
; <<>> DiG 9.8.3-P1 <<>> -t ns @192.5.6.30 twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56292
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; AUTHORITY SECTION:
twitter.com.        172800  IN  NS  ns3.p34.dynect.net.
twitter.com.        172800  IN  NS  ns4.p34.dynect.net.
twitter.com.        172800  IN  NS  r01-01.ns.twtrdns.net.
twitter.com.        172800  IN  NS  r01-02.ns.twtrdns.net.
twitter.com.        172800  IN  NS  d01-01.ns.twtrdns.net.
twitter.com.        172800  IN  NS  d01-02.ns.twtrdns.net.
;; ADDITIONAL SECTION:
ns3.p34.dynect.net. 172800  IN  A   208.78.71.34
ns4.p34.dynect.net. 172800  IN  A   204.13.251.34
r01-01.ns.twtrdns.net.  172800  IN  A   205.251.195.113
r01-02.ns.twtrdns.net.  172800  IN  A   205.251.197.74
d01-01.ns.twtrdns.net.  172800  IN  A   208.78.70.34
d01-02.ns.twtrdns.net.  172800  IN  A   204.13.250.34
;; Query time: 171 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Sep 27 16:00:31 2017
;; MSG SIZE  rcvd: 270
到这里的结果就和刚才不一样了,可以看到,192.5.6.30 这个服务器正常返回了应该负责解析 twitter.com 的真实 ns 的服务器,既然都做到这里了,就继续下去吧,继续从里面随便抓一个出来
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
$ dig@208.78.71.34 twitter.com any
;; Truncated, retrying inTCP mode.
; <<>> DiG 9.8.3-P1 <<>> @208.78.71.34 twitter.com any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16674
;; flags: qr aa rd; QUERY: 1, ANSWER: 28, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;twitter.com.           IN  ANY
;; ANSWER SECTION:
twitter.com.        293 IN  SOA ns1.p26.dynect.net. zone-admin.dyndns.com. 2007137844 3600 600 604800 60
twitter.com.        13999   IN  NS  ns2.p34.dynect.net.
twitter.com.        13999   IN  NS  r01-02.ns.twtrdns.net.
twitter.com.        13999   IN  NS  r01-01.ns.twtrdns.net.
twitter.com.        13999   IN  NS  d01-02.ns.twtrdns.net.
twitter.com.        13999   IN  NS  d01-01.ns.twtrdns.net.
twitter.com.        13999   IN  NS  ns3.p34.dynect.net.
twitter.com.        13999   IN  NS  ns1.p34.dynect.net.
twitter.com.        13999   IN  NS  ns4.p34.dynect.net.
twitter.com.        79  IN  A   199.59.148.10
twitter.com.        79  IN  A   199.16.156.6
twitter.com.        79  IN  A   199.59.150.7
twitter.com.        79  IN  A   199.16.156.102
twitter.com.        79  IN  A   199.16.156.38
twitter.com.        79  IN  A   199.16.156.70
twitter.com.        79  IN  A   199.59.149.198
twitter.com.        79  IN  A   199.16.156.198
twitter.com.        79  IN  A   199.59.149.230
twitter.com.        79  IN  A   199.59.148.82
twitter.com.        79  IN  A   199.16.156.230
twitter.com.        79  IN  A   199.59.150.39
twitter.com.        300 IN  TXT "v=spf1 ip4:199.16.156.0/22 ip4:199.59.148.0/22 ip4:8.25.194.0/23 ip4:8.25.196.0/23 ip4:204.92.114.203 ip4:204.92.114.204/31 ip4:23.21.83.90 include:_spf.google.com include:_thirdparty.twitter.com -all"
twitter.com.        300 IN  TXT "google-site-verification=h6dJIv0HXjLOkGAotLAWEzvoi9SxqP4vjpx98vrCvvQ"
twitter.com.        600 IN  MX  10 aspmx.l.google.com.
twitter.com.        600 IN  MX  20 alt2.aspmx.l.google.com.
twitter.com.        600 IN  MX  30 ASPMX3.GOOGLEMAIL.COM.
twitter.com.        600 IN  MX  20 alt1.aspmx.l.google.com.
twitter.com.        600 IN  MX  30 ASPMX2.GOOGLEMAIL.COM.
;; Query time: 21 msec
;; SERVER: 208.78.71.34#53(208.78.71.34)
;; WHEN: Wed Sep 27 16:01:08 2017
;; MSG SIZE  rcvd: 891
我们可以发现挂上 VPN 之后的解析流程才是正确无误的过程,但是为什么不挂上就不能正确解析?自然是 DNS 服务器被污染了。并且拦截的方式似乎也很弱智,发现 UDP 53 口的包带有 twitter.com 字样,直接返回一个随即、胡编出来的 IP 地址,也不管人家到底是不是直接要去查 twitter.com 的 A 记录。为了证明这种猜想,继续做一些试验吧。不如发一个错误的 DNS 包出去,看看返回什么结果。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ dig@202.204.49.251 twitter.com -t ns --->> 查询的服务器是 202.204.48.251
; <<>> DiG 9.8.3-P1 <<>> @202.204.49.251 twitter.com -t ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28290
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;twitter.com.           IN  NS
;; ANSWER SECTION:
twitter.com.        64  IN  A   243.185.187.39
;; Query time: 24 msec
;; SERVER: 202.204.49.251#53(202.204.49.251)
;; WHEN: Wed Sep 27 16:02:43 2017
;; MSG SIZE  rcvd: 45
这里的服务器是 iBeiKe 在教育网内的服务器,对于外网没有开除了 80 的任何口,而且也没有 53 的 UDP 开着,果然,够弱智!

tcpdump 抓包

tcpdump 这个东西虽然叫做 tcpdump,但是 UDP 抓起来也没有问题,随便抓抓 DNS 的解析包,不需要什么重型武器,这种轻量级别就很好用了。环境和上面一样,我用的无线网络,所以在 Mac OS X 的接口就是 en1 了。不上 VPN 看看结果如何吧
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
$ sudotcpdump -i en1 -vvv udp
16:05:10.189549 IP (tos 0x0, ttl 64, id51997, offset 0, flags [none], proto UDP (17), length 57)
    192.168.0.86.61289 > a.gtld-servers.net.domain: [udp sumok] 4731+ NS? twitter.com. (29)
16:05:10.190103 IP (tos 0x0, ttl 255, id51444, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.86.53167 > ns.szptt.net.cn.domain: [udp sumok] 14187+ PTR? 30.6.5.192.in-addr.arpa. (41)
16:05:10.200364 IP (tos 0x0, ttl 45, id59500, offset 0, flags [DF], proto UDP (17), length 73)
# 假的结果返回
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sumok] 4731 q: NS? twitter.com. 1/0/0twitter.com. [1m38s] A 59.24.3.173 (45)
16:05:10.201166 IP (tos 0x0, ttl 197, id55906, offset 0, flags [none], proto UDP (17), length 84)
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sumok] 4731* q: NS? twitter.com. 1/0/0twitter.com. [1m] A 59.24.3.174 (56)
16:05:10.258033 IP (tos 0x0, ttl 51, id56581, offset 0, flags [none], proto UDP (17), length 298)
# 正确的返回
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sumok] 4731- q: NS? twitter.com. 0/6/6ns: twitter.com. [2d] NS ns3.p34.dynect.net., twitter.com. [2d] NS ns4.p34.dynect.net., twitter.com. [2d] NS r01-01.ns.twtrdns.net., twitter.com. [2d] NS r01-02.ns.twtrdns.net., twitter.com. [2d] NS d01-01.ns.twtrdns.net., twitter.com. [2d] NS d01-02.ns.twtrdns.net. ar: ns3.p34.dynect.net. [2d] A 208.78.71.34, ns4.p34.dynect.net. [2d] A 204.13.251.34, r01-01.ns.twtrdns.net. [2d] A 205.251.195.113, r01-02.ns.twtrdns.net. [2d] A 205.251.197.74, d01-01.ns.twtrdns.net. [2d] A 208.78.70.34, d01-02.ns.twtrdns.net. [2d] A 204.13.250.34 (270)
16:05:10.429786 IP (tos 0x0, ttl 51, id0, offset 0, flags [none], proto UDP (17), length 73)
    a.gtld-servers.net.domain > 192.168.0.86.61289: [udp sumok] 4731 q: NS? twitter.com. 1/0/0twitter.com. [3m29s] A 78.16.49.15 (45)
16:05:10.718695 IP (tos 0x0, ttl 59, id0, offset 0, flags [DF], proto UDP (17), length 101)
    ns.szptt.net.cn.domain > 192.168.0.86.53167: [udp sumok] 14187 q: PTR? 30.6.5.192.in-addr.arpa. 1/0/030.6.5.192.in-addr.arpa. [1d] PTR a.gtld-servers.net. (73)
16:05:11.124993 IP (tos 0x0, ttl 4, id27621, offset 0, flags [none], proto UDP (17), length 157)
    192.168.0.119.63409 > 239.255.255.250.ssdp: [udp sumok] UDP, length 129
16:05:11.125357 IP (tos 0x0, ttl 1, id29662, offset 0, flags [none], proto UDP (17), length 304)
    192.168.0.149.50587 > 239.255.255.250.ssdp: [udp sumok] UDP, length 276
16:05:11.227349 IP (tos 0x0, ttl 4, id27623, offset 0, flags [none], proto UDP (17), length 157)
    192.168.0.119.63409 > 239.255.255.250.ssdp: [udp sumok] UDP, length 129
唔,有人抢在正确的包之前跑来了。你为什么这么积极呢?为什么呢…

转自:https://2.botu.me/post/2763.html

在 Ubuntu 部署 VPN 隧道 WireGuard

$
0
0
来源: https://steemit.com/cn/@curl/ubuntu-vpn-wireguard
内容修订:https://github.com/aturl/awesome-anti-gfw





关于 WireGuard

WireGuard 是简单、快速、高效并且安全的开源 VPN 软件,它采用先进的加密协议,基于 Linux 内核实现。
WireGuard 项目官方网站 https://www.wireguard.com/
WireGuard 源代码由开发者自我托管,代码仓库 https://git.zx2c4.com/WireGuard/
WireGuard 源代码在 GitHub 的镜像仓库 https://github.com/WireGuard

在服务器端部署 WireGuard

WireGuard 跨平台,参照官方给出的快速安装指南 https://www.wireguard.com/install/

服务器环境以 Ubuntu 系统为例

生成公钥、私钥、共享密钥

sudo mkdir -p /etc/wireguard && sudo chmod 0777 /etc/wireguard && cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey | wg genpsk > presharedkey
打印输出私钥
cat privatekey
+Cr59JzbCKz9rESqimHGi5C2QfIRYZ5xVMssiTAEqV4=
打印输出公钥
cat publickey
bco6xIgfp++iFBj6vmDr27tAXfgYsppn/wyUJRcFgUc=
打印输出共享密钥(可以不生成,配置文件中不是必须的)
cat presharedkey
Vv0MdBNolqbnsBPQPf0ttJecOw2QC8QqWBVieNtvoIo=

编辑并保存 wg0 配置文件 wg0.conf

sudo vi wg0.conf

wg0.conf 配置文件内容如下:

ListenPort = 监听端口 1194
PrivateKey = 服务器私钥
PrivateKey = 连接节点公钥(由客户端生成)
AllowedIPs = VPN 隧道的内网 IP 段
[Interface]
ListenPort = 1194
PrivateKey = +Cr59JzbCKz9rESqimHGi5C2QfIRYZ5xVMssiTAEqV4=

[Peer]
PublicKey = 1lq23n/oNwYosnf0xMadtrIcC+droND9fg/wiS0aEhw=
AllowedIPs = 10.100.0.1/24

设置服务器的 NAT 流量转发

sudo vi /etc/sysctl.conf

找到这一行 #net.ipv4.ip_forward = 1 去掉注释符 “#”

net.ipv4.ip_forward = 1

执行 sysctl 并生效

sudo sysctl -p

在服务器端添加虚拟网卡 wg0,设置隧道 IP 和 iptables 规则

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 10.100.0.1/24
sudo ip link set wg0 up
sudo wg setconf wg0 /etc/wireguard/wg0.conf
sudo iptables -A FORWARD -i wg0 -j ACCEPT
sudo iptables -A FORWARD -o wg0 -j ACCEPT
sudo iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE
检查 wg 设置是否正常
sudo wg show

正常情况应该输出以下内容:

interface: wg0
public key: 1lq23n/oNwYosnf0xMadtrIcC+droND9fg/wiS0aEhw=
private key: (hidden)
listening port: 1194

peer: 8+9jGlxuwyGUWtUk8/NZMAl1Ax577KAvnXJY0EeuNkQ=
endpoint: 12.34.56.78:61353
allowed ips: 10.100.0.0/24
latest handshake: 0 days, 8 minutes, 19 seconds ago
transfer: 0.60 GiB received, 0.93 GiB sent
服务器端设置完成。

设置客户端

客户端系统 Ubuntu/Debian/ArchLinux 参照官方给出的快速安装指南 https://www.wireguard.com/install/

sudo mkdir -p /etc/wireguard && sudo chmod 077 /etc/wireguard && cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
打印输出私钥
cat privatekey
SHBjWA3uAYAZc+TUvr6PcTA5SVQnt+aSVkdlZhlg1Hk=
打印输出公钥
cat publickey
8+9jGlxuwyGUWtUk8/NZMAl1Ax577KAvnXJY0EeuNkQ=

编辑并保存 wg0 配置文件 wg0.conf

sudo vi wg0.conf

wg0.conf 配置文件内容如下:

ListenPort = 监听端口 1194
PrivateKey = 本地客户端私钥
PrivateKey = 服务器端公钥(由服务器端生成)
AllowedIPs = VPN 隧道的内网 IP 段
Endpoint = 远程服务器公网 IP 和端口
PersistentKeepalive = 连接心跳包的唤醒间隔
[Interface]
ListenPort = 1194
PrivateKey = SHBjWA3uAYAZc+TUvr6PcTA5SVQnt+aSVkdlZhlg1Hk=

[Peer]
PublicKey = bco6xIgfp++iFBj6vmDr27tAXfgYsppn/wyUJRcFgUc=
AllowedIPs = 0.0.0.0/0
Endpoint = 12.34.56.78:1194
PersistentKeepalive = 25

在本地客户端

在客户端,添加虚拟网卡 wg0 并设置 IP 和路由

sudo ip link add dev wg0 type wireguard
sudo ip address add dev wg0 10.100.0.101/24
sudo ip link set wg0 up
sudo wg setconf wg0 /etc/wireguard/wg0.conf
sudo ip route add 12.34.56.78 via 192.168.1.1
sudo ip route del default
sudo ip route add default dev wg0

客户端设置完成,Ping 测试 VPN 隧道

ping 10.100.0.1

ping 输出如下

PING 10.100.0.1 (10.100.0.1) 56(84) bytes of data.
64 bytes from 10.100.0.1: icmp_seq=1 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=2 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=3 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=4 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=5 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=6 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=7 ttl=44 time=103.50 ms
64 bytes from 10.100.0.1: icmp_seq=8 ttl=44 time=103.50 ms
^C
--- 10.100.0.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 828ms
rtt min/avg/max/mdev = 103.50/103.50/103.50/0.00 ms
说明 VPN 隧道已通
用 curl 命令测试隧道的流量转发状态
curl ifconfig.me
显示 IP 为服务器的公网 IP
12.34.56.78
curl 获取到了服务器的公网 IP,流量转发成功

Disable WireGuard,禁用 WireGuard

删除添加的虚拟网卡、IP 和路由,或者重启系统,将恢复默认设置

服务器端

sudo ip link del dev wg0

本地客户端

sudo ip link del dev wg0
sudo ip route del 12.34.56.78 via 192.168.1.1
sudo ip route del default
sudo ip route add default via 192.168.1.1

其他

WireGuard 设计原理和使用方法参考 https://www.wireguard.com/
WireGuard 支持各种 Linux 发行版,目前 Windows 和 macOS 客户端(Go 实现)以及 Android 应用都在开发中。
WireGuard 在数字权利遭受强权政府日益侵害的国家,能有效捍卫网络用户的数字权利。
WireGuard 在中国、俄罗斯、伊朗等网络审查严重的国家,能有效突破网络封锁,突破 GFW 封锁,加密访问被封锁的网站,自由使用互联网。



柏拉图:地穴寓言

$
0
0


来源: https://zh.wikipedia.org/wiki/%E5%9C%B0%E7%A9%B4%E5%AF%93%E8%A8%80

苏格拉底描述了一个地下洞穴住所,洞里有一条宽阔的通道通向地面。这个山洞里居住着终生被关押在那里的囚犯。他们被捆绑着大腿和脖子坐在那里,以致他们只能朝前看到洞穴的墙壁,而不能转身回头顾望。因此,他们永远看不到背后的出口,也根本不知道有这么一个出口。他们也不能看到自己和其他囚犯。他们唯一能看到的是他们面对的墙壁。他们的住所被身后远方高处燃烧的火炬照亮。囚犯只能看见这唯一的亮光,照亮着墙壁。但是看不见光源。在墙上他们只能看见光影。

监狱内部同火炬之间,有一堵不会遮挡光线的矮墙。沿着这堵墙壁,有人来回穿梭,搬运着不同的物品,包括一些用石头和木头做的人体和其他生物模型。这些物体高出那堵矮墙,但是他们的搬运者比墙低。其中的一些搬运者相互交谈着,另一些则保持沉默。

由于囚犯面对洞穴墙壁,那些来回移动的物体,在墙上投射的阴影,被穴居人看见当作会移动的影子。但他们想到有人在搬运这些东西。当有人说话时,洞壁上的回声,就如同那些影子自己在讲话一样。因此,囚犯以为那些影子会说话。他们把这些影像当作生物,把所有发生的事情理解为这些生物的行为。墙上演绎的事情,对他们来说都是真相,当然是真实的。他们从这些影子中研发出一整套学问,试图从它们的出场和动作中,找出一系列规律,并且预告将要发生地事情。那些预测最准确的人,还会得到嘉奖。

接着,苏格拉底问Glaukon(苏格拉底的谈话对象),如果给一名囚犯松绑,让他站起来,转身向出口望去,看见这些以往所见的影子的原型,能否想象这时会发生什么?这个人可能会在强光刺激下痛苦不堪,产生错乱。相比于过去熟悉的光影,他可能会认为届时所看到的东西不是现实的。因此,他可能希望重新返回自己习惯的位置。因为他相信只有在洞壁上能看见真相。而不去会相信一个善意解放者的相反说教。

如果使用武力将松绑的囚徒从洞穴中拖出来,穿过对他来说陡峭难行的通道,来到地面,他也许会觉得特别别扭,愈发神志错乱。因为璀璨的阳光会使他睁不开眼,开始时什么都看不见。慢慢地他也许会适应看见的新鲜事物。其过程也许是首先识别光影,然后是水中的倒影,最终才是人和事物本身。如果往上看,他也许会先习惯夜晚的星空,然后才是白天的日光,最后他也许才敢于直接目视太阳,从而感受太阳的独特之处。只有这时他才能理解,太阳造就了光影。有了这些经历和认识,他应该不再愿意回到洞穴,去探究那里的光影学问,获取其它囚徒的赞誉。

如果他还是回到故地,那么他肯定需要重新慢慢地适应洞穴里的黑暗。由此他肯定会在一段时间内,落后其它囚徒对后续光影估算能力。而洞里其它的囚徒则会认为,他在上面把眼睛弄坏了。他们会嘲笑他,觉得离开洞穴显然是宗蚀本生意,根本不值得一试。如果有人试图解放他们,把他们带到地上,他们会杀了他,如果可能的话。

“未阅先焚” 微信朋友圈图片过滤功能分析

$
0
0
来源: https://citizenlab.ca/2018/08/%E6%9C%AA%E9%98%85%E5%85%88%E7%84%9A%EF%BC%9A%E5%BE%AE%E4%BF%A1%E6%9C%8B%E5%8F%8B%E5%9C%88%E5%9B%BE%E7%89%87%E8%BF%87%E6%BB%A4%E5%8A%9F%E8%83%BD%E5%88%86%E6%9E%90/

阅读报告全文(英文)



本报告分析了微信朋友圈上的敏感图片过滤技术。微信是中国腾讯控股有限公司旗下的即时通讯应用,目前是中国最受欢迎的聊天软件之一,也是全球排名第四的最流行聊天软件。朋友圈是微信上最常用的功能之一,其中图片是用户最期望看到的内容分享形式。

根据中国相关法律法规,互联网公司往往需要对内容进行过滤。公民实验室此前的研究报告发现了微信的“一APP两制”关键词过滤机制,在新浪微博Tom-Skype和新浪UC等即时通讯软件,以及直播平台上的审查机制。此前,我们留意到微信除了过滤关键词,部分与敏感事件相关的图片也会被审查。

主要发现
  • 微信采用了两种不同的算法过滤朋友圈中的敏感图片:一种是基于光学字符识别(Optical character Recognition)的文字检测方法,该方法用以过滤包含敏感词的图片;另一种是基于图像相似度的对比,该算法用以过滤与微信不良图片数据库中的图片相似或吻合的图片。
  • 我们发现微信采用的文字识别算法与大部分文字识别算法有所相通,即其对包含文字的图像进行灰度化(grayscale)和通过斑点合并(blob merging)来识别文字。
  • 微信基于图片相似度的的图片过滤算法并没有使用机器学习来判别目标图片是否属于某个不良图片类别。
  • 在研究这两种不同算法的同时,我们发现用以检测不良内容的技术同样可以被用来反审查。
  • 通过分析了解文字识别算法和图片相似度检测算法,我们发现了这两种算法并非万无一失。算法的弱点让用户得以通过编辑图片,使经过编辑的图片与原敏感图片在能够被普通读者识别理解的同时欺骗机器算法,从而不被过滤。

全新 VPN 翻墙技术 WireGuard 简单教程攻略

$
0
0
来源:https://yuesheng01.blogspot.com/2018/07/vpn-wireguard.html

今天闲来没事干浏览手机的时候, 在手机主页左侧的Feed 新闻推荐页面推送了一个新闻。大意是说,美国的一个参议员给美国技术协会写了一篇公开信,内容是希望政府单位能够淘汰老旧的VPN技术,使用全新的WireGuard 作为替代。文章还提到,如果使用以前的VPN技术,一个数据包传输大概要经过7次的复制转发,十分的浪费带宽和资源。

心想既然美国参议员都这么建议了说明这个WireGuard的确是个好东西,于是经过一番google 后,成功进行了跳墙。好了废话不多说,上硬货:

一、准备工作


我身边只有MAC一台,所以我以此作为基本的进行讲解(估计其他版本差别也不是太大)。

首选,大家都知道VPN也少不了C-S(客户-服务器)的模式。所以找一个靠谱的服务器,现成的最好。那么就推荐一个AzireVPN. 这是一个付费的VPN服务提供商但是却提供 免费的WireGuard 服务。也就是所有的WireGuard都是无限期免费使用。啥都不多说人家给我们免费使用了还说什么。

官方公告: 
Our WireGuard tunnel is currently free for everyone
Our internal tests has been running smoothly, therefore we are now interested in testing our WireGuard infrastructure at larger scale. For this reason, we decided to open up ours WireGuard servers for free. Simply sign up to connect to all of ours WireGuard servers, available in each of ours locations.
所以,赶紧去注册一下,获取帐号激活账号就好。

二、安装

1、首选Mac电脑默认没有安装HomeBrew,所以我们需要安装HomeBrew。
打开终端:复制粘贴下面code到你的终端中回车。

 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
2、等待homeBrew下载安装结束后。安装wireguard
 brew install wireguard-tools jq
3、等待结束后添加AzireVpn提供的服务器脚本
 curl -LO https://www.azirevpn.com/dl/azirevpn-wg.sh && chmod +x ./azirevpn-wg.sh && ./azirevpn-wg.sh
这个过程中你会获取到相应的服务器地址以及名称类似于下图:


4、启动wireguard
好了所有都安装都完成了,下面就是启动了。寻找对应的上图中的框框中提示的,里面已经含有了启动代码,所以复制粘贴启动就可以了

 wg-quick up azirevpn-us1 
5、暂停wireguard
 wg-quick down azirevpn-us1 
三、Android 客户端

1、官方提供的Android 客户端软件,下载软件后再从这个配置连接下载配置信息,打开手机软件选择导入即可。

2、这个客户端是独立存在的,不需要我们手动配置参数,直接导入下载的配置使用就行。

四、后记

再怎么说服务器不是自己搭建的,所以随时都有可能被停用。后期找到相应的服务器搭建方法后再补充。

走過不留痕跡:用半小時加密你的一切

$
0
0


每個人都有的電子郵件信箱,是最容易被忽視的個資罩門;如果信箱被攻破,入侵者不僅可以閱讀通訊內容,還可以重設你幾乎所有帳號的密碼。千萬別再覺得「反正我的email內容沒什麼好看的」,所以就不重視它的安全了。

「唯有偏執狂得以生存」
— Andy Grove
前Intel執行長Andy Grove是個逃離匈牙利共產統治的難民,後來研讀工程、並成為領導個人電腦世代革命的重要人物。他在與巴金森氏症對抗多年之後,於2016年初過世。
如果連像他這樣的重要人物都告訴我們「做人必須偏執」,應該有他的理由值得我們參考才對。
何況,Grove並不是唯一提醒我們要事事小心的大人物。美國聯邦調查局(FBI)的局長也告訴我們,平常沒事的話最好把電腦上的攝影鏡頭蓋起來
或許有人覺得,「我是個守法公民,有什麼好害怕的?」;何況英國政府也說,「如果你沒什麼見不得人的事,當然就不用緊張」。
其實不然。即使你是守法公民,還是必須提高警覺;而且當然應該維護隨身設備、其中的檔案、以及跟家人朋友之間的往來通聯記錄。
「你讓一個最誠實的人寫下六行字交給我,我就能找到把他吊死的罪狀。」
— 紅衣主教李希留(Richelieu),1641年
在本文中,筆者將會告訴你如何運用先進的加密技術,來保護你的個人資訊;只要一些簡單的步驟,你的個人隱私保障就可以再往前邁進一大步。

每個人都該知道的基本資安概念

話說在先:筆者建議的每一種方法都不需要花錢、也完全合法。如果你晚上睡覺的時候會鎖門,就應該沒有理由不用加密方式保護個人資料。
現在,就讓我們開始做些準備。
在本文中,「入侵者」指的是任何沒有經過你允許,就試圖取得你個人資料的一方,包括駭客、特定公司、甚至政府都包含在內。而「安全」和「隱私」就是一般的意義;但在現實之中,只要有人為操作,任何系統都不會有100%的安全或隱私。
只要你的手機、電腦、或是帳號經過保護處理,其中的資料就只是一堆經過加密的「亂碼」;無論入侵者的能力多強,都很難對它進行解密。

方法1:在電郵信箱上採用雙重認證機制

幾乎每個人都有的電子郵件信箱,其實也是最重要的個資罩門,但卻往往被忽視。如果電郵信箱被攻破,入侵者不僅可以閱讀你的通訊內容,還可以用它來重設你幾乎所有帳號的密碼,包括社群網站、甚至網路銀行等等。
所以,千萬別再覺得「反正我的email內容沒什麼好看的」,所以就不重視電郵信箱的安全了。
而要保護自己的信箱,最簡單有效的方法就是啟用「雙重認證」(two-factor authentication)機制。簡單的說,雙重認證就是在登入的時候,在標準密碼之外再多加上一層認證,例如透過手機簡訊收取另外一組密碼。
啟用雙重認證機制,可以大幅降低信箱被入侵的可能性。如果你用的是Gmail信箱,可以透過這個連結來啟用:
拜託,請現在就馬上設定雙重認證,真的。請先快去設好,再回來讀這篇文章,謝謝。

方法2:將電腦硬碟內容加密



WindowsmacOS系統上都內建了將整顆硬碟內容加密的功能,只要開啟就可以了,非常簡單。have built-in full-disk encryption. You just need to turn it on.

方法3:在手機上使用密碼保護

利用指紋辨識來保護手機是很好。但往往還不夠安全。
以美國而言,法律在「不自證有罪」的前提之下,允許人們有不交出手機密碼的權利;但法庭卻可以要求相關人士用指紋開鎖。另外一個問題是,萬一手機已經被入侵者破解,你並不能像更換密碼一樣,更換自己的指紋。
一般來說,手機都會允許使用者嘗試輸入10次密碼,全部錯誤的話才會把手機鎖死。如果你的4位數密碼在以下的「常用列表」之中,請趕快換掉:
1234  
9999
1111
3333
0000
5555
1212
6666
7777
1122
1004
1313
2000
8888
4444
4321
2222
2001
6969
1010
進階建議:
如果你為了方便,還是堅持使用指紋辨識開機,萬一你遭遇「被迫以指紋解鎖」的情境,可以立即將手機關機;這樣一來,再開機之後就無法直接以指紋開機,而必須先輸入密碼。
譯按:原文所描述的其實是手機主人「萬一被逮捕」的情境,而如前文所述,美國法律雖然保障不說密碼的自由,但可以強制用戶以指紋當場開機;所以如果透過立即關機,讓手機變成「只能用密碼開啟」的狀態,可以拖延官方取得手機內容的時間。
如果你不是在美國,這一招就不一定有效,但或許在某些情境下還是可以參考使用。

方法4:在不同的服務上使用不同的密碼

密碼本身就不是一種絕對安全的設計;連Facebook老闆Mark Zuckerberg,都曾經在他的LinkedIn帳號上用過「dadada」這種糟糕的密碼。
我之所以會知道,是因為先前曾經有駭客公開了1億1,700萬組電郵帳號密碼,而Zuckerberg的也是其中之一;也因為email帳號密碼外洩,Zuckerberg的Twitter和Pinterest帳號也全部跟著淪陷。



所以,如果可能的話,每個地方用的密碼最好都不一樣。當然,記住這麼大一堆密碼是有點麻煩的事情,所以請多多利用密碼管理工具:

方法5:使用經過加密的傳訊工具

「Signal」是一個由電子前哨基金會所推出、並有許多關心資安的人常用的傳訊工具。它的用法跟一般傳訊工具一樣,也可以拉群組、分享照片或影片等等。
不同的地方,在於Signal傳送的所有內容都經過加密。
Signal是一個免費的開源軟體,有各種行動版和電腦版;只要五分鐘就可以安裝好、並且開始和朋友互相傳訊。
以下就是安裝步驟簡介:
1. 安裝Signal


2. 邀請朋友也來安裝


3. 開始傳訊


好了,現在你不管在線上跟朋友聊什麼,都不用再擔心;因為透過Signal傳送的交談內容,幾乎是無法監控和破解的。
對了,Signal也可以用來打經過加密的語音電話。

方法6:記得,瀏覽器的「無痕模式」並不夠安全

即使你使用了Chrome瀏覽器上的「無痕模式」(Incognito Mode)、或是Firefox上的「私密瀏覽」,下列的幾種人士都還是有可能看到你的瀏覽記錄:
  • 網路服務商
  • 學校、公司、或是任何上網場所的網路管理員;
  • Google或任何其他瀏覽器的出品廠商。
無論是Internet Explorer、Safari、Opera、或是其他任何瀏覽器,都不是絕對私密。如果你需要私密度「相對比較高」(沒有人能保證100%)的瀏覽工具,可以試試「Tor」。

方法7:使用「Tor」進行私密瀏覽

「Tor」是「The Onion Router」的縮寫,其中的「洋蔥」(Onion)代表經過層層加密偽裝來隱藏使用者的資料;Tor是免費的開源軟體,而且也算好用。
譯按:Tor是用來為通訊內容加密的工具,最好搭配同樣安全的瀏覽器使用。iOS版已經將兩者整合在一起,而Android版則可以搭配Orfox瀏覽器
1. 下載Orbot
以下是下載安裝Android版(稱為「Orbot」)的範例:




3. 開啟Orbot


4. 開啟Orfox


5. 確認安全連線是否成功

安裝完之後,可以試試連結「check.torproject.org」這個網址看看是否成功。如果成功,代表你接下來的通訊內容都經過安全加密,要追蹤或破解你的瀏覽記錄會相當困難。

方法8:使用私密搜尋工具

如果你覺得Tor還是不方便,至少可以試試不會追蹤你瀏覽記錄的「DuckDuckGo」搜尋引擎。


DuckDuckGo本身當然並不像Google一樣,有無數人力投入開發各種搜尋功能;但在安裝之後,你可以在搜尋字串前面加上「!google」來將Google搜尋功能加密,例如:


如果有時間的話,也推薦你一讀資安專家Bruce Schneier所寫的《Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World》一書;筆者從中學到了很多東西,而且一直都遵守著書上所揭櫫的原則。
編按:上述這本書的中文版為《隱形帝國:誰控制大數據,誰就控制你的世界》,由如果出版社出版。但由於原書是在2016年出版,所以其中的部分工具或觀念可能不是最新的,但大多數的資安原則應該還是不變的。

(編譯/ Fred Jame原文出處

2018-08 - 翻墙技术与大事记

中国正式屏蔽ABC网站,声称互联网是“充分开放的”

$
0
0




中国网络安全监管机构已证实因为澳大利亚广播公司ABC的网站违反了中国的互联网法律法规,因此受到了屏蔽,但该部门拒绝透露具体原因。

澳大利亚广播公司ABC网站和手机应用程序通常可供中国网民使用,不受"防火墙"审查的限制,但从8月22日开始却突然无法登陆。 

"中国互联网是充分开放的。 我们欢迎各国互联网企业为中国网民提供良好的信息服务。"在多次发出澄清要求之后,中国国家互联网信息办公室 的一位官员向ABC发出了声明:

" 但国家网络主权应当得到维护, 对于一些境外网站违反中国法律法规, 传播谣言信息, 淫秽色情, 赌博暴恐以及危害国家安全,损害国家荣誉等违法有害信息, 我国有关部门依据《网络安全法》等法律法规, 有权通知有关机构采取技术措施和其他必要措施阻断传播。"

这位拒绝透露姓名的官员表示,政府部门"有权采取技术措施以阻止传播"。

其他两个中国政府部门的官员拒绝透露澳大利亚广播公司ABC是如何违反中国法律法规的,也拒绝引用任何内容作为案例。

在中国境内登陆其他澳大利亚新闻网站,包括费尔法克斯(Fairfax)、新闻有限公司(News Limited)和SBS都没有受到影响。

澳大利亚驻北京大使馆的外交官注意到了此事,并将此描述为在中国境内登陆ABC网站"当前所遇到的困难"。但澳大利亚外交及贸易部(DFAT)却拒绝对此进一步发表评论。

在澳大利亚政府宣布将阻止两家中国电信公司参与澳大利亚5G网络基础设施建设后第二天,中国就屏蔽了对ABC网站的登陆。

对中国科技巨头华为造成主要影响 的这一决定对该公司造成重大打击,促使中国外交部敦促澳大利亚"放弃意识形态偏见"。

但中国政府的官方消息来源称,对于华为的决定不太可能造成对ABC网站的审查和屏蔽。 

"澳洲佳"在与中国官方媒体机构合作下成立,并使用中国域名,服务器在中国国内托管,受到北京的审查。屏蔽之时正值澳大利亚广播公司开始运营新中文新闻服务一年之后。该服务取代了"澳洲佳"(Australia Plus)网站。


更广义地说,中国在过去18个月中一直严厉批评澳大利亚媒体的报道,官员们指责媒体的报道造成两国关系恶化。

今年早些时候,北京的外交消息人士称,中国官员对ABC的报道特别不满,因为ABC是一家公共广播电视公司。

中国审查机构经常性封锁一些国际新闻网站,例如《纽约时报》和英国广播公司BBC的中文网。

英文网站则不常遭屏蔽,但BBC网站因为最近改用加密的HTTPS技术,就一直受到了屏蔽。

在中国政府正阻止其公民获得ABC内容的同时,中国国营媒体却可以不受任何限制地通过在线和及CCTV和CGTN付费电视频道向澳大利亚观众播出。

600亿美元的大大大新闻,微博上竟然没有评论!

$
0
0

来源微信号:xiaoyanggc , 笑央 


看了新闻的朋友应该都知道了,西历2018年的9月3日下午,中非合作论坛北京峰会开幕式于人民大会堂隆重举行。

 

开幕式上,大国领袖正式宣布,为推动"八大行动"顺利实施,中国愿以政府援助、金融机构和企业投融资等方式,向非洲提供600亿美元支持。

 


按理说这么重大的国际+财经+时政新闻,怎么着也该引发舆论热议才对。可是笑央打开微博发现,不仅没有上热搜,甚至连个独立的话题都没有。

 

最奇怪的是,所有转发这一新闻的媒体账号下方,竟然空空如也,没有一个评论!真真是奇哉怪也,如此重大之新闻,国人竟能冷漠视之?


到底是怎么回事呢?且待我一个个去搜一下。


先是环球时报,这是一家极其正统的机构,一向以民族主义代言人自居,这么能够彰显民族自豪感的新闻,必然是要转发的。


 

果不其然,环球时报以视频的方式转发了这一新闻,视频中截取了领袖宣布600亿美元支持的视频。页面显示,该视频已获得395万次观看。如此庞大的数据,评论数显示却只有3516,可是等我打开来看的时候,却又显示此处无人评论。

 

难道是管理员把评论给删了?我不服气,发了个评论,做个测试,发现分明显示是可以评论的。可刷新之后我发现,评论已经不复存在,并被提示由于博主的设置,评论将由Ta筛选后显示。

 


我又去看了人民日报的微博,和环球时报一样,人民日报的微博也是以视频的方式发布,甚至连所有的文案都和环球时报一毛一样。页面显示,人民日报的视频观看次数达到了424万次,并且有着5400多个评论。

 

我欣喜若狂,打开评论区,却发现实际评论数只有数十条。不过好在这一次终于有了评论,总算可以窥测一下国民的真实心声了。

 

我挨个看了一下,发现果然人日的留言就是有素质,整齐划一地全是支持600亿美元提案的——好像不是提案诶。

 

我注意到排名第一的留言,留言是这么说的:"40年前非洲黑哥们把咱们抬进了联合国,现在咱们有钱了,是时候报恩了。"嗯,说的太感人了,我差点都想把我的20块钱存款捐出去了。

 


这位网友如此高的境界,我一定得认识一下啊。于是我贱贱地点开了该网友的微博主页,并顺带着点开了个人头像,然后眼前一亮,好一个有情有义的人日好网友!


 

我又看到了排名第二的留言,留言内容是"共同繁荣 肝胆相照  荣辱与共",三个成语铿锵有力,意义深刻,令我瞬间泪目。



那么这位网友又会是怎样一个身份呢?


我继续贱贱的点开了该网友的微博主页,然后发现人家的微博认证是"微博监督员",也不知道这个认证是真是假,反正是令我虎躯为之一震,差点尿失禁。


 

继续逛,发现一个留言充满了正能量的网友。其简简单单的两个字"支持",简洁有力地响应了领袖的心声,四个大拇哥更是形象生动!



再点开微博主页,点击头像一看,头像是这样的:


 

贱贱的我竟然逛了逛这位网友的微博,发现有限的几条微博里,清一色全是这种类型的自拍照。


厉害了,人日的管理员还真会筛选留言呢。


我又先后看了中国新闻周刊、财经网等机构账号的微博,600亿新闻的微博下方均无一人评论。

 

不过某网友提醒我说,北京晚报是开放过评论的,后来不知出于什么原因,全给清理了。我表示不信,好好的评论,还能给清理了?


见我不信,网友给了我之前的评论截图,果然,人民的声音是曾经真实存在过啊。


只不过与人日的评论风格迥异,北京晚报下面的评论是这个画风的:

 

 

Word天呐,这么喜大普奔的消息,网友留言怎么一个个苦大仇深的样子。这种言论、这种气度岂是唐唐大国国民所应有?


你瞅瞅人日下面的留言,你瞅瞅留言人日的网友那素质,那头像,那觉悟……那才是非洲兄弟喜闻乐见的画面啊!


与此同时,我赶紧找到注册名为@京东发言人的微博,嗯,微博下方骂京东的留言还在。



顿时一阵感慨,在你国,企业再牛逼,跟看不见的手相比,也还是弱爆了啊。

扫盲 HTTPS 和 SSL/TLS 协议[4]:历史版本的演变及 Record 协议的细节

$
0
0

文章目录
★名词解释
★SSL/TLS 历史版本的演变及差异
★Record 协议概述
★Record 协议的结构
★各种类型 Record 简介
  俺一直在等 TLS 1.3 定稿(之所以这么期待,因为 1.3 是一次【大】升级)。
  前些天(2018年8月),IETF 终于发布了 RFC 8446,标志着 TLS 1.3 协议大功告成。于是俺就来继续完成本系列的后面几篇。
  本系列的前一篇,咱们聊了"密钥交换/密钥协商"的相关算法。从这篇开始,会逐步谈及协议的细节,今天就从 Record 协议说起。由于恰逢 TLS 1.3 新鲜出炉,俺也顺便聊聊 SSL/TLS 历史上几个版本的演变及差异。


★名词解释


  对于本文会涉及到的几个专业术语,先放上相应的解释。

◇块加密算法


  "块加密算法"又称"分组加密算法",洋文叫做"Block Cipher",相关的维基百科链接在"这里"。
  顾名思义,就是这类加密算法要求:被加密的明文数据必须分成【相同大小】的若干坨(每一坨的大小称为【块长度】)。
  以目前流行的对称加密算法 AES 为例。AES 的【块长度】是"128 比特"(16字节)。也就是说,AES 要求被加密的明文必须是【128位】的整数倍。
  由于【块加密算法】对明文的长度有要求,所以用这类算法对明文数据进行加密之前,要先进行【补齐】——在明文数据末尾追加一些垃圾数据,使之达到【块长度】的整数倍。

◇流加密算法


  与"块加密算法"相对应的是"流加密算法",洋文叫做"Stream Cipher",相关的维基百科页面在"这里"。
  与"块加密算法"最大的差别在于——流加密算法对明文数据的长度【没有】要求(可以是任意字节数)。
  典型的流加密算法是 RC4(顺便提一句:RC4 里面的 R 也就是 RSA 的那个 R)

◇MAC(消息认证码)


  MAC 是洋文"Message Authentication Code"的缩写,维基百科的介绍在"这里"。这玩意儿是通讯及密码学的常见的概念——用 MAC 算法来确保某个信息在传输的过程中【没有】被篡改。
  说到这儿,某些聪明的同学已经联想到【散列函数】——用散列函数计算出来的哈希值确实可以用来作为 MAC。这种基于哈希(HASH)的"消息验证代码"也称作"HMAC"。不了解哈希算法的同学可以看这篇博文:《扫盲文件完整性校验——关于散列值和数字签名

◇MAC 的几种搞法


  常见的有如下三种。俺从维基百科剽窃了对应的流程图,大伙儿看图就明白其原理,省得俺浪费力气打字了。

  Encrypt-then-MAC (EtM)
不见图 请翻墙
  先加密明文得到密文,再根据密文计算 MAC,最后把密文与 MAC 合并成一坨

  Encrypt-and-MAC (E&M)
不见图 请翻墙
  对明文加密得到密文,对明文计算 MAC,最后把密文与 MAC 合并成一坨

  MAC-then-Encrypt (MtE)
不见图 请翻墙
  对明文计算 MAC,把明文与 MAC 合并成一坨,然后一起加密

◇AE(带认证的加密)


  传统的加密算法只负责实现【保密性】,而不负责【完整性】。这么说有点抽象,俺举个例子:
  假设你把一段明文 P 加密为一段密文 C,通过网络把 C 发送给另一个人。中途如果被攻击者篡改了(把 C 修改为 C'),那么接收方收到 C' 之后,还是可以正常进行解密操作(当然,解密之后得到的就不再是 P 了,而是得到一段无意义的数据)
  为了解决上述弊端,业界引入 AE(Authenticated Encryption)算法的概念。也就是说,AE 算法不但能做到【保密性】还可以做到【完整性】。
  刚才扫盲的三种 MAC 实现方式,【从理论上讲】就可以算 AE 啦。但上述那三种 MAC 的实现方式有个弊端——【解密】的一方还要自己进行 MAC 的验证操作。这种搞法既麻烦又增加额外风险。比如说:写解密代码的程序猿万一太粗心忘记进行验证,岂不前功尽弃?

◇【真正的】 AE


  为了避免上述提到的弊端,密码学界那帮专家又捣鼓出一些新的算法(比如 CCM、GCM)。这些算法可以在解密的同时验证数据的有效性,而且这些算法也【不】需要再额外存储一个独立的 MAC 数据。
  本文后续部分提及的 AE,如果没有特别说明,就是指这类【真正的】AE。
  知名的那些 AE 算法,可以组合现有的加密算法。比如说:从 TLS 1.2 开始引入的 GCM 和 CCM,这两个 AE 算法都可以组合 AES128 与 AES256 加密算法。
  组合现有加密算法的好处不光是避免重新发明轮子,而且还可以充分利用硬件加速。比如 AES 作为对称加密的标准算法,某些芯片(比如 Intel/AMD)会把 AES 算法直接做成 CPU 指令,以实现硬件加速。

◇AEAD


  AEAD 是洋文"Authenticated Encryption with Associated Data"的缩写,普通话叫做"带关联数据的认证加密"。简而言之,AEAD 是 AE 的变种。为了方便理解,俺再来找个栗子:
  比如说在网络通讯中,数据包的【头部】必须是明文且保证完整性;而数据包的【载荷】既要加密(保密性)又要保证完整性。这时候 AEAD 算法就派上用场啦——数据包的【头部】就是 AEAD 算法里面的【关联数据】。

◇前向保密 / 完美正向加密


  在本系列的前一篇《密钥交换(密钥协商)算法及其原理》,俺已经补充了一个章节,简单扫盲了一下"回溯性破解"与"前向保密"的概念。
  所以这里就不再浪费口水啦。


★SSL/TLS 历史版本的演变及差异


  趁着 TLS 1.3 正式发布的大好时机,简单扫盲一下 SSL/TLS 各个版本的差异。

◇SSL 1.0


  在本系列的第一篇,俺曾经提到:SSL 是上世纪90年代中期,由网景公司设计的。早期设计者是网景公司的 Taher Elgamal(一位埃及的密码学家)。此人也被誉为"SSL 它爹"。
  SSL 1.0 【从来没有】正式发布过,所以业界对它了解不多。之所以没有正式发布,据说是设计完之后发现了若干严重的安全缺陷,就不好意思再拿出来丢人现眼。

◇SSL 2.0


  SSL 2.0 是 1995 年正式发布滴,坦率地说,协议设计比较粗糙。
  比如俺在前一篇介绍过"密钥交换算法"和"身份认证算法"。在这两方面,SSL 2.0 都仅仅支持 RSA 这一种算法。
  另一个值得吐槽之处是:SSL 2.0【没有】考虑到"前向保密"(洋文是"forward secrecy"),因此会遭遇【回溯性破解】的风险。(关于"前向保密"与"回溯性破解",请看本文开头的名词解释)

◇SSL 3.0


  SSL 2.0 发布之后不久,又被发现若干安全漏洞。所以又赶紧在 1996 年发布了 SSL 3.0 版本。(接连两个版本都不太灵光,看来"SSL 它爹"的水平实在令人不敢恭维)
  这个 3.0 版本可以说是另起炉灶——换了几个密码学专家,【重新设计】了 SSL 协议。所以 SSL 3.0 相比 SSL 2.0 有很大差别。
  关于 SSL 3.0 的权威技术规范,可以参见 RFC 6101

  请允许俺稍微跑题一下:
  重新设计 SSL 3.0 的那些专家,为首的是来自斯坦福大学的 Paul Kocher——此人堪称密码学奇才,SSL 3.0 发布的那年(1996),他才23岁(回想俺23岁的时候,在密码学方面是只菜鸟,真是情何以堪)。
  在同一年,他还发表了篇论文,描述了一种【全新的】密码学攻击方式——timing attack(基于时间因素的边信道攻击)。这种攻击手法的原理,说起来并不算复杂,但很有创意,之前从来没人想到过。

◇TLS 1.0


  TLS 1.0 是 1999 年发布滴,技术规范参见 RFC 2246
  为啥从 SSL 改名为 TLS 捏?主要是安全性在 Web 世界中越来越重要,因此 IETF组织急需把 SSL 的协议【标准化】,为了以示区别,另外起个名字叫 TLS(洋文"Transport Layer Security"的缩写)。
  虽然协议名改了,但其实 TLS 1.0 与 SSL 3.0 的差别不大。这点从协议版本号也可以看出来——TLS 1.0 内部的协议版本号其实是【3.1】。

◇TLS 1.1


  TLS 1.1 是 2006 年发布滴,技术规范是 RFC 4346
  发布该版本的主要动机是:修补 CBC(cipher-block chaining)相关的漏洞,以防范某些攻击(比如"padding oracle attack")。
  在 1.1 版本,原有的"【隐式】初始化向量"改为"【显式】初始化向量",修正了 CBC 方式下填充数据的缺陷。

◇TLS 1.2


  TLS 1.2 是 2008 年发布滴,技术规范是 RFC 5246
  相比 TLS 1.1 的变化如下:
支持 AEAD 加密模式(参见 RFC 5116
加密算法废弃了 DES、DES40、IDEA、RC2
HMAC 增加了 SHA256

◇TLS 1.3


  俺写本文时,TLS 1.3 刚刚新鲜出炉没几天(2018年8月),其技术规范是 RFC 8446
  所谓的"十年磨一剑",这个 1.3 版本是一次雄心勃勃的升级,相对 TLS 1.2 加了不少东西,也删了不少东西。考虑到篇幅,俺挑几个主要的来说说:
首先要表扬的是:TLS 1.3 完善了 SNI(Server Name Identification)扩展,非常有利于翻墙工具借助【依附的自由】对抗网络封锁;
其次是强制使用"完美正向加密(PFS)",所以很多做不到 PFS 的密钥协商算法在 TLS 1.3 规范中被无情地抛弃了(比如:RSA、静态 DH、静态 ECDH...);
传统的 HMAC 也被无情地抛弃了,今后只使用 AEAD 方式来保障完整性(关于 AEAD,请看本文开头的名词解释);
原有的对称加密算法只保留 AES(3DES、RC4 废弃),另增加 CHACHA20 流加密算法;
压缩特性被废除(以消除 CRIME 攻击的风险);
初始握手的过程有大的改变(这个等下一篇再聊)
......


★Record 协议概述


  很多介绍 SSL/TLS 的文章都把 record 协议给忽略了。可能这些文章的作者觉得 record 协议不太重要。但俺出于负责任的心态,觉得还是有必要跟大伙儿聊一下。
  SSL/TLS 协议在通讯的过程中会把需要传输的数据分成一坨一坨的,每次都只发送或接收一坨。在洋文中,每一坨称为一个 record。下面要聊的"Record 协议",就是用来定义这个 record 的格式。


★Record 协议的结构


  Record 协议比较简单,主要结构见下表:

字段名称字段长度备注
类型1字节
版本2字节TLS 1.3 废弃,仅留作向下兼容
载荷长度2字节
消息0~N 字节
消息认证码0~N 字节TLS 1.3 不需要该字段
填充0~N 字节

◇类型(type)


  "类型"字段是个枚举值,协议允许的有效值如下:
十进制十六进制含义备注
0x1420ChangeCipherSpec(切换到加密方式)TLS 1.3 废弃
0x1521Alert(告警)
0x1622Handshake(握手)
0x1723Application(应用层数据)
0x1824Heartbeat(心跳)始于 TLS 1.3
  (关于表格中每一种类型,下面会有详细介绍)

◇版本(version)


  "版本"字段含两个字节,分别表示:主版本号 和 次版本号。有效值如下:
主版本号次版本号含义
0x20x0SSL 2.0
0x30x0SSL 3.0
0x30x1TLS 1.0
0x30x2TLS 1.1
0x30x3TLS 1.2
  注:从 TLS 1.3 版本开始,"版本"字段已经被废弃,仅用于向后兼容。

◇长度(length)


  "长度"字段含两个字节,表示载荷长度。
  对于【明文】的 record,【没有】"消息认证码"字段,也【没有】"填充"字段——"载荷长度"也就是消息的长度。
  对于【加密】的 record——"载荷长度"是"消息、消息验证码、填充"三者的长度之和。
  SSL/TLS 协议规定了长度字段最多只能表示 0~16384 字节(214 = 16384)。

◇消息(message)


  每个 record 的"消息"字段的内容取决于"类型"字段。关于这个"消息"字段,待会儿再聊。

◇消息认证码(MAC)


  关于 MAC 这个概念,参见本文开头部分的名词解释,此处不再浪费口水。
  在 SSL/TLS 协议中,MAC 对于明文的 record 没有意义(为啥没意义,请自行思考)。
  对于【加密】的 record,要分两种情况:
其一,如果是【传统的】块加密与流加密,会带有额外的 MAC;
其二,如果使用 AEAD 加密模式,其本身已经内置了【完整性】的校验,不需额外的 MAC。
  前面提到,AEAD 是从 TLS 1.2 开始引入,到了 TLS 1.3 就【只支持】AEAD 啦。所以 TLS 1.3 【没有】MAC 部分。
  SSL/TLS 各个版本实现【完整性】的方式:
算法SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2TLS 1.3
HMAC-MD5
HMAC-SHA1
HMAC-SHA256
AEAD

◇填充(padding)


  只有当 record 是加密的,并且使用的加密算法属于【块加密算法】,才会使用"填充"字段。


★各种类型 Record 简介


  从 Record 协议的头部类型字段可以看出,总共有5种类型的 Record。下面简单说一下:

◇握手(Handshake)


  Record 协议的"类型"字段为 22(0x16),表示这条 record 是 Handshake 类型。
  "握手"的意思就是——通讯双方初次打交道,需要交换一些初始化的信息。
  对于 SSL/TLS 协议,为了建立起【可靠的】加密信道,通讯双方需要在握手的过程交换很多信息(加密算法、压缩算法、MAC 算法、等等)。所以这个握手的过程是比较复杂滴,需要耗费很多口水。俺留到本系列的下一篇,专门来聊"握手的细节"。
  由于握手的过程,加密信道尚未建立,所以用来进行握手的 record 是【明文】滴,并且也【没有】"MAC"字段及"填充"字段。

◇切换到加密方式(ChangeCipherSpec)


  Record 协议的"类型"字段为 20(0x14),表示这条 record 是 ChangeCipherSpec 类型。
  这个 ChangeCipherSpec 也是跟握手过程相关滴,留到下一篇。
  注:从 TLS 1.3 版本开始,ChangeCipherSpec 类型的 record 已经被废弃,仅用于向后兼容。

◇应用层数据(Application)


  Record 协议的"类型"字段为 23(0x17),表示这条 record 是 Application 类型。
  也就是说,这条 record 的载荷部分存放的是上层(应用层)协议的数据。既然传输的是上层数据,肯定得是【加密】滴!但不一定有"MAC"字段。要看具体的 SSL/TLS 版本(如下):
1. 对于 TLS 1.1 及之前的版本,总是使用 HMAC 进行完整性校验,所以总是含有"MAC"字段。
2. 对于 TLS 1.2,如果握手之后采用 AEAD 加密模式,就没有 MAC;反之,则有 MAC。
3. 对于 TLS 1.3 及之后的版本,只支持 AEAD,【不】再有"MAC"字段。
  另外,在 TLS 1.2 及【之前】的版本中,还支持"对应用层数据进行压缩"。本来俺还想聊聊这方面的实现细节。但是 TLS 1.3 已经【废弃】了压缩选项(为了防 CRIME 攻击),恐怕未来版本也不会再有压缩选项了。搞得俺也没积极性来聊这个话题了 :(

◇告警(Alert)


  Record 协议的"类型"字段为 21(0x15),表示这条 record 是 Alert 类型。
  这种类型的 record 用来发送警告或出错信息。
  在通讯的过程(包括握手过程)中,有时候某一方会发现不对劲(比如收到的数据出现缺失或错误),这时候就要发送一条 Alert 类型的 record 给对方。
  不对劲的情况分为两种,洋文分别称之为 Warning 和 Fatal。两者的差别在于:
Warning 表示通讯出现【不稳定】的情况(这种"不稳定"通常是【可恢复】滴)
Fatal 表示通讯出现【不可靠】的情况(比如:证书失效、数据被篡改。这种"不可靠"通常是【不可恢复】滴)
  如果不对劲的情况属于 Warning,通讯可能会继续也可能会断开;如果不对劲的情况属于 Fatal,通讯会在发送 Alert 之后立即断开。
  这种类型的 record,其"消息"字段仅有2字节,头一个字节表示告警的"级别/Level"(1表示 warning,2表示 fatal);后一个字节表示具体的描述(有一个对照表,用不同的整数表示不同的情况)。
  如果在握手【之后】发送告警,此时双方已经建立起加密信道,则告警 record 的"消息"字段是【密文】的。
  如果在握手【之前】发送告警,此书尚未建立加密信道,则告警 record 的"消息"字段是【明文】的。

◇心跳(Heartbeat)


  Record 协议的"类型"字段为 24(0x18),表示这条 record 是 Heartbeat 类型。
  这种类型的 record 用来发送心跳信息。
  所谓的【心跳】,主要用来确认"通讯的对端依然正常"。在 SSL/TLS 连接建立之后,有可能在某些情况下出现【通讯空闲】(上层的协议在某个时间段没有数据传输)。这时候就需要依靠【心跳机制】来判断对方是否还活着。
  由于"心跳"的传输是在加密信道建立之后,所以"心跳"的 record 是加密的。
  关于这个心跳机制的技术细节,请参见 RFC6520(链接在"这里")。
  这个心跳协议的 RFC 发布于2012年(晚于2008年的 TLS 1.2),因此目前只有 TLS 1.3 版本才支持它。

媒體人、淘寶店主、畢業生、普通網民......自由如何被閹割?

$
0
0

「不知道有多少人在做着幻夢,又不知道有多少人從這可怖的幻夢中尖叫着醒來。這個國家的人心在逐漸沉下去,而上位者還泡在人血裏不斷上浮。」






【編者按】上週,端傳媒刊出《全面審查時代》一文,試圖通過23位中國大陸媒體從業者的口述描出那張審查大網的變遷與樣貌,小心翼翼的試探,不斷縮窄的出口,從政治到文娛蔓延的無力,在翻手禁令覆手指令的大手之下,每一篇報導都經歷著自我審查與新聞審查組建的層層關卡。

與此同時,讀者們也留下了他們的「審查故事」:他們有的同樣是媒體從業者,有淘寶店主,有畢業設計被批判「反中國」的學生,也有被銷過數次新浪微博帳號的普通網民。

過去,不少人曾期待信息時代的技術進步可以推動社會變革,然而,曾經在傳統媒體中傳達的「禁令」也迅速延伸至以《網絡安全法》為標誌的網絡平台管控。不斷增加的敏感詞列表與自媒體銷號名錄堆砌成敢怒不敢言的緘默,人們用代號暗語互相詢問著:「還有這件事?」


【聚焦】中国无死角“数字独裁”体系下的模范公民

$
0
0


中国正在对其14亿公民建立一套数字独裁统治体系。对一些人来说,"社会信用评级"系统会带来便利——而对某些人来说,则会带来惩罚。

听起来,一个反乌托邦的未来已经在中国发生。而且这正在创造或是破坏着人们的生活。

中国共产党称其为"社会信用评级",并表示这套系统将在2020年前完全投入使用。

一份中共官方规划纲要称,在几年内,该系统将"使守信者处处受益、失信者寸步难行"。

社会信用就好比中国14亿公民的个人记分卡。

在一个已经实施的试点项目中,每位公民都被分配到800分内的一个分数。其他项目中是900分。

全文http://www.abc.net.au/chinese/2018-09-18/china-social-credit-leave-no-dark-corner/10264922

为何我选择不依赖微信生活

$
0
0




中国广州——微信已经成为在中国生活不可或缺的一部分。作为中国对WhatsApp、Facebook、优步(Uber)和苹果支付(Apple Pay)的回应,它将这些国际品牌提供的所有功能整合到一个手机应用程序中。中国人用它来做各种事:与朋友分享近况、发送消息、群聊到组织聚会,乃至进行数字支付。
尽管它具有相当大的实用性,但这款应用让我感到不安。
几年前,当微信开始流行时,我在朋友圈(微信中相当于Facebook时间线的功能)发布了一张香港纪念天安门事件的烛光守夜的照片。半小时后,我的老板打电话给我,骂我做出了"危险、不当"的行为,命令我"马上删掉"。我不得不照办,但忍不住想知道这件事为什么泄露得那么快。由于朋友圈中的帖子应该只能被微信上的朋友看到,显然,不是朋友举报了我,就是当局正在监视我的微信活动。这两种情况都让我非常不舒服。
我很快意识到我的情况不是孤例。在接下来的几年里,我在新闻中听到很多关于微信用户的故事,他们因为在朋友圈里发布的内容遭到审讯或逮捕。有些帖子在政治上很敏感,还有一些帖子则是抱怨当地警察
我还在微信另外两个主要的功能"群聊"和"公众号"当中亲身体验到了审查制度。虽然中国人通常不会在公共场合谈论政治,但他们在私下都非常直言不讳,而群聊则提供一个私密的、非正式的环境。随着人们在群聊中交换政治观点,聊天群组和参与者的帐户往往会在没有任何警告的情况下被删,成员们不知道自己逾越了什么界限。据《南华早报》报道,今年有三人因为"在群聊中发表一篇关于共产党权力斗争的文章"而被封号。微信上还有2000万个公众号,是为那些有兴趣接触大众的人准备的。那里的文章受到严格审查,许多关注程度较高的帐户被暂时禁声或甚至永久封号。
随着时间推移,我在微信上许多朋友的账户因为政府审查口中的"恶意传播谣言"而被封号。这些人大多不问政治,只是分享关于引发公众愤慨的丑闻的批评文章,比如问题疫苗,以及对高层人物的#MeToo指控;被封号的时候,他们没有接到任何通知,说他们分享的哪一篇文章被视为虚假或恶意信息。由于大多数用户现在都有数千个联系人,甚至银行账户都与微信相关联,因此账号被封会给他们在财务和社交方面带来麻烦。随着恐惧气氛蔓延,是越来越多的自我审查
几年前,对这种严厉审查制度感到不满的人会使用微信的外国竞争对手,如Facebook、Twitter、Line、Facebook Messenger、Telegram或WhatsApp。随着时间推移,这些公司在中国相继屏蔽。到2017年底,微信成了防火墙后唯一被允许运行的消息应用程序。据该应用程序背后的中国科技集团腾讯称,到2018年初,它每月有10亿活跃用户。
为应对政府不断增加的压力,微信和类似的公司正在大力投资人力和过滤技术,以加强审查用户的能力。官方媒体《环球时报》报道,"中国庞大的网络体量"必须"密切监控危险内容"。在流量繁忙期间,可能涉及到监控"每天数万亿的帖子、语音、照片和视频。"
2017年9月,中国管理互联网的政府机构中央网络安全和信息化委员会办公室发布了新的规则,加强对群聊的控制,呼吁群主向当局报告涉嫌违规和犯罪行为,并要求提供此类服务的企业进行合作及技术援助。它还引入了一种新的机制来控制在线讨论:管理者根据信用系统对群聊用户进行评级;如果在多次违规后信用额度下降太多,他们对聊天群组的访问权限就会暂时被停止。
2017年12月,中国宣布与腾讯合作,在微信上实施国家身份证系统时,我意识到微信已经超越了商业信息平台,成为中国电子统治计划的一部分。
由于微信,我们生活中的一切都变得容易被国家掌握,腾讯在我们不知情的情况下(更不用说征求我们同意)分析我们的购物习惯、旅行计划甚至是约会偏好,并且将其变现
我曾试图说服我认识的人改用其他具有端到端加密功能的信息服务应用,但无济于事。他们的大多数联系人都在微信上,而且非常依赖它的服务,他们认为没有理由离开。每当我提出隐私问题时,通常的回答是,"如果你没什么可隐瞒的,为什么要介意政府访问你的数据呢?"可悲的是,这与中国搜索引擎巨头百度首席执行官李彦宏的话不谋而合:他说,如果中国人"可以用隐私换取便利、安全或者效率,在很多情况下,他们就愿意这么做"。
在过去的几年里,我尽力远离微信;我的手机上还有这个应用程序,但我已经学会了不依赖它而生活。虽然典型的中国互联网用户将三分之一的移动在线时间用在这个应用上,并且每天访问它10次乃至更多次,但我每周只查一两次微信。我尝试在中国使用现金或信用卡付款,并且在国外使用WhatsApp和Telegram。放弃隐私和言论自由以换取便利,这不是我愿意做的交易。

关于中国审查版搜索引擎:谷歌内部泄露的私下会议与该公司的公开声称完全矛盾

$
0
0



如您所知,"对内和对外"的态度在很多时候是有区别的,也是为什么人们普遍对内幕消息的兴趣远高于宣传稿。但是对于谷歌来说,这里的"区别"简直就是天壤之别,他们为什么要掩盖[对于一家公司来说单纯的赚钱兴趣]?我们似乎能闻到一股奇怪的味道,它可能远非"怕丢人"这么简单。本文是 The Intercept 最新获取的谷歌内部会议记录的副本,其中很多细节足以验证我们曾经对谷歌做出的分析……但这可能不是故事的全部

谷歌搜索引擎主管 Ben Gomes 说,"我们必须专注于我们想要实现的目标,确保当序幕拉开时我们已经做好了一切准备"。

此时是 7月18日星期三,Gomes 正在向谷歌内部员工发表演讲,他们正在开展一个秘密项目,为中国开发一个审查版搜索引擎,将"人权问题"、"学生抗议[指64]"和"诺贝尔和平奖[指刘晓波]"等均列入黑名单。

这里是 The Intercept 获得的此次会议记录,Gomes 在会议中称:"你们已经加入了一项非常重要的工作,这事关公司的利益……我不得不承认这是一段艰难的旅程。但我确实认为这是一个非常重要且有价值的工作。我希望我们能够尽快抵达目的地。"

Gomes 开玩笑说总统特朗普的不可预测性,并感叹于美中之间正在进行的所谓贸易战,据称导致谷歌与北京共产党官员之间的谈判被放缓,这一计划中的谈判如果启动,谷歌将要求北京批准谷歌推出审查版搜索引擎 — 也就是进入中国市场。

Gomes 于 1999 年加入 Google,并且是该公司搜索引擎项目背后的关键工程师之一,他表示希望该平台的审查版搜索引擎可以在 6 到 9 个月内推出,但有可能会更快。"这是一个我们以前从未涉及过的领域,"他说,"因此,我觉得我们不应该在时间表中加入太多明确的内容。"

自 The Intercept 首次公布有关代号为 Dragonfly 的审查版搜索引擎的详细信息至今已有两个月了。从那时起,该项目一直在面临人权组织、谷歌员工、美国参议员、甚至副总统迈克彭斯的批评,他上周四呼吁谷歌"立即停止开发 Dragonfly 应用程序,这将加强共产党的审查、侵犯中国客户的隐私。"(后面有详细分析)

谷歌拒绝回答有关 Dragonfly 项目的问题或疑虑。 9 月 26 日,一位谷歌高管首次面临对审查计划的公众质疑,当时 Keith Enright 告诉参议院商业科学和运输委员会,"是有一个项目叫 Dragonfly",但他说,"我们距离在中国推出产品还有很远。"当被要求提供具体细节时,Enright 直接拒绝了,说他"不清楚该项目的范围或超出范围的部分。"

直接参与建立审查项目的谷歌高级管理人员在很大程度上避免了任何公众监督。但是在 9 月23 日,Gomes 在庆祝谷歌成立 20 周年的活动中遇到 BBC 记者时,简要地对 Dragonfly 项目发表了简要的评论。

"现在,我们所做的只是一些探索,"Gomes 告诉记者说,"但由于我们还没有任何推出什么东西的计划,所以我没什么可说的。"

One Google source said Gomes's comments to the BBC were "bullshit."

Gomes 的声明与公司的官方路线保持一致。但是,这与他私下告诉那些正在研究 Dragonfly 项目的员工的内容完全不一致 — 这让人感到不安。一位谷歌消息人士告诉 The Intercep,Gomes 给英国广播公司的评论是"胡说八道"。

7月的会议上,Gomes 告知员工,该公司的计划是尽快启动审查版搜索引擎 — 并且一旦收到北京的批准,就可以"准备好"快速部署。

关于 Gomes 对内部工作人员的评论您可以在最下面阅读全文,突出显示了谷歌关于 Dragonfly 项目的公开和私下声明之间形成的鲜明对比。这个秘密项目自 2017 年春季以来一直在进行 — — 涉及约 300 名员工,其中大多数人都是全职工作的。这远远超出了他们公开声称的所谓"探索",并且推出该项目的计划是完善的,尽管该公司努力压制这些信息,但最近几周内谷歌自己的一些员工也强调了这一点

Gomes 的言论同时揭示了为什么谷歌有兴趣在 2010 年高调离开后如今再次返回中国,当时该公司曾宣称由于担心言论自由和安全问题而"无法继续"。

在向工作人员解释为什么关于 Dragonfly 项目的工作"非常重要"时,Gomes 引用了中国市场的庞大规模为由,称"我们正在谈论的是 Google 的下一个十亿用户" — — 再次证实了我们在两个多月前的分析:西方市场已经饱和,谷歌和 Facebook 都需要在非西方加速铺展。尤其是中国,该国没有基于公民切身利益的隐私保护法案,其公民也不重视自己的隐私权,尤其是该国政府对伪装成"智能城市"的大规模监视项目的垂青,谷歌需要借助搜索引擎作为跳板,以进入中国市场。他们瞄准的是这个庞大的数据库,对监视资本主义者们来说这才是真金白银。在这里看到更多《"智能城市"究竟是个什么鬼?!》。

但是,上述显然只是表面逻辑。由于我们没有基于此事的内幕消息(想必美国的独立媒体也没有,除非情报机构内部人士泄露出来)于是不方便做更多推测。不过我们想借此指出一些可能被忽视了的线索,虽然不会得出结论,但这些线索应该对您的思考有一定帮助。

1、首先认识谷歌。当然这绝不是什么新闻,在美国不是,可在中国很大程度上似乎仍是新闻,即 谷歌从来都是情报部门的监视计划项目。我们推荐过一本书《When Google Met Wikileaks 》,出版于四年前,其中解释了几乎完整的谷歌内幕 — 最重要的是揭示了该公司的真实属性。这大概是第一部也是最透彻的一部阐述硅谷巨头的作品。

如果您没有读过这本书,这里还有一份在线可读的报告,该报告来自 INSURGE INTELLIGENCE:一个由众筹资助的调查性新闻项目 — 也就是说它是独立的,与任何权势无关,它揭露了美国情报界如何资助、培育谷歌,作为全球信息战的工具。

事实上相关文献大量存在,其中最为热门的包括 Tim Shorrock 的 "Spies for Hire",从一个相比下较浅的角度揭示了"美国情报 — 工业联合体"的内幕:当今的科技巨头为什么能成为巨头,因为它们是当年通过向情报界提供技术服务和产品而开始的(否则他们没有今天这般强大)上面链接可在线阅读。这份资料曾被多家国际隐私权利组织引用。顺便提一个在美国几乎家喻户晓的常识:真正做政治决策的是情报机构而不是白宫,仅举一篇文章详细阐述了这点《United States overseas operations: Role of CIA — Jacob G. Hornberger

2、关于利益关系的逻辑。就如我们曾经分析过的,此事有两个观察角度:

  • 如果你使用地缘政治博弈的角度来看,即"高堡奇人",美国 — 中国在数字技术世界的"均分天下",那么这件事可能是错的,相当于将谷歌的能力 — 也就是美国情报机构的实力"切割"出一块可观的部分送给了北京,将球踢入对方的球门?;
  • 但如果你换个角度看,从技术本身的可利用性角度,那么这事很可能就是"对的",因为对美国情报机构来说有它大有好处,将意味着情报机构能够更深入地了解在中国"谁或哪些组织是对北京政权冲击力最大的、中国人普遍关心的问题都有哪些、谁在关切当局不喜欢的内容、中国社会的最典型特征都是些什么"等等,这些信息具有高度的情报价值。

而且后一种和前一种并不冲突,它们是完全一致的,中国人有曰"知己知彼方百战不殆",情报从古到今都是无价之宝。并且它也符合上述 1 中关于 CIA 构建谷歌的目的 — — 北京一直明白或者说怀疑这种目的的存在,这才是真正的原因关于为什么中国的 GFW 一直在屏蔽硅谷巨头,并同时打造本土的几乎功能一样的克隆版数字应用和数字技术。这不仅仅是简单的舆论控制目的。

抵制"北方叙事"的危地马拉活动家们也曾经暗示过这点,即 后台是情报机构的硅谷巨头的全球覆盖将侵蚀小国的利益[包括文化独立性]。再推荐一本书《Science of Coercion: Communication Research and Psychological Warfare, 1945–1960》关于全球心理战的历史以及其对传播学发展的决定性作用。您将能从中感受到危地马拉活动家的焦虑所在(请看英文原版)。

3、那么为什么参议员和彭斯都在公开反对该项目呢?对于前者,一方面美国参议员也很可能并不了解情报机构的计划,这是基本政治模式,也是为什么美国民间称其为"deep state";另一方面也有可能只是姿态,毕竟"协助[不论任何一种]审查"都是违背美国基本价值观的;而对于后者彭斯,审查版搜索引擎显然是一个极其惹眼的论据,作为中期选举前的舆论铺垫,不消说此论据具有显著的价值。

综上可见,作为谷歌高官,该项目只能秘密操作,一方面它不光荣,另一方面它不是简单的赚钱生意。也就解释了为什么该公司一直以来极力掩盖此事(在其项目启动一年多后我们才得知,还是多亏了独立媒体的揭露)。Gomes 在内部讲话中所表现出来的信心是非常有趣的观测点,虽然他自己也显然无法推测风向将会如何,但作为生意人,为了一个直到现在还不知道能不能开张的买卖做出如此令人印象深刻的投入,那将意味着他心里有底,此事包赚不赔

为什么不论北京是否同意谷歌也不会赔钱?想想美国情报机构全球一流的情报预算吧。

The Intercept 的报告也明确指出,如今 Dragonfly 项目已被曝光、随之而来的不论是内部和外部的强烈反对,似乎都在使 Google 的领导地位不稳定?并且在该项目计划的方向上产生一定程度的不确定性?然而并没有。根据与 Dragonfly 项目有关信息来源,工程师们正在依照管理层的指示行事,继续在审查版搜索引擎项目上投入努力,整体呈现一种积极发展的状况

我们不做任何判断,您可以结合我们上述给出的线索来分析这件事。不论任何时候,我们坚决反对一切审查。是一切!

The Intercep 联系了 Gomes 以征求意见,但这货没有回复通过电子邮件和短信发送的请求。周六,当有人再次问及 Dragonfly 时他搞了一个非常拙略的借口,"我听不清你在说什么,只知道你在说话",他说,并迅速挂断了电话。

以下是 Ben Gomes 在 2018 年7月18日向内部为审查版搜索引擎项目工作的 Google 员工发表的讲话(摘要版)全文在这里读到

我知道这对你们中许多人来说是一个漫长的过程,我首先承认这点。毕竟很多人已经开始研究这个问题了,在一个暂时没有明显结果的项目上努力工作并不容易。再次我要对你们所有人表示感谢。在这项工作的过程中,您承担了对公司来说极为重要的任务 — 我们为全世界所有用户提供服务的基本使命。在此过程中,我认为我们将获得很多"附带的好处",不仅来自直接的工作,还来自基于中国工作的其他附加利益。

我用两种方式来考虑 Google。其中之一是技术,另一个是产品和客服。因此,从服务用户的角度来看,毫无疑问 — 我们正在讨论的是下一个十亿用户…这个世界上有 50 亿成年人,那么我们为什么要考虑下一个十亿用户呢?好吧,其中的确有一些人没有启用互联网,等等,但对于那些支持互联网的人群来说,现在我们正在遗漏的很大一部分人都在中国。

所以有机会 — 所有人都会知道这点 — 这显然是为更多人提供服务的最大机会。如果你认真对待我们的使命,那就是我们关注的重点。这并不意味着它会很容易。其中许多事都不容易,而且你们现在从个人经验中也已经了解到了这点。还有政治气候问题。未来是非常难以预测的。六到九个月内[推出该项目]。但我们通常都无法预测最近三天的政治变动,更不用说政治的最近一年了,[或]过去两三年。所以我们只是不知道未来在某些方面会有什么发生,我们必须专注于我们想要启用的内容,确保它有机会发布时我们有充分的准备。

你们一直在以这种身份工作,这并不容易。而我们正在与您合作,为确保您的职业生涯不会受此影响。困难的部分在于如此长时间内保持动力,但是,许多困难和有价值的旅程都是如此,为了保持这种动力,当你抵达目标时就会感受到更甜蜜的收获。

我还想说 — 我没想到我们能够从搜索的角度做出改变,我们已经能够做到这点。由于我们还没有得到来自中国内部的信息,我们可能会取得边际进展,我们会尽力而为。但是各位……我真的很惊讶我们已经取得了如此大的进步。 …我非常感谢你们所做的工作。

我认为中国是最有意思的市场之一,可以说是当今世界上最有意思的市场。关注中国市场将让我们学到东西,因为在某些创新方面中国是领先于世界的。我们需要了解那个国家发生的事,以激励我们。这不仅仅是一条单行道。中国会教给我们一些我们不知道的东西……这对于我们 Google 来说是非常有价值的,可能不仅仅是在中国,在其他地方也一样。

每个人都注意到了一些在中国发生变化的关键模型,商业模式,但我敢肯定还有更多我们今天尚未了解的其他创新。通过努力,您将成为创新世界的窗口。总的来说,我只想感谢你们所做的所有工作。我请大家耐心等待一段时间,我不得不承认这是一段艰难的旅程。但我确实认为这是一个非常重要且有价值的旅程。我希望我们能够尽快抵达目的地。

虽然我们说过这将是六到九个月内[就会推出的计划],但世界是动态的,几个星期前还没有人会预料到美国总统会责怪美国与俄罗斯的问题,而俄罗斯外交部会在 Twitter 上做出回应说:"我们同意。"所以……只能说他反复无常,一些事有可能迅速发生根本性变化。所以在某种程度上,在我们的规模上,我们需要保持这种选择性,以防突然间世界发生变化,也许他会忽然决定他的新朋友是习近平。这是一个我们以前从未生活过的世界。所以我觉得我们也不应该过多地确定时间表。

……我只能说我们要把眼光放长远一点,世界的步伐正在发生变化……所以我们应该提高警惕,以确保只要时机到来,我们不会错过它。

……

首先基本可以肯定的是,Gomes 没有对其工作人员说明全部,至少此前已经有明确报道,在该项目计划被泄露之后谷歌内部紧急维稳封锁了相关资料;其次,谷歌"背后的人"也很可能没有对谷歌说明全部,这部分不做推测。但现在您至少可以了解到一个大概了。◾️

全面審查時代:中國媒體人正在經歷什麼?

$
0
0

来源:https://theinitium.com/article/20180910-mainland-censorship-journalist-in-china/
特約撰稿人:江雁南,獨立記者,自由撰稿人,發自香港,2018-09-10

這是一篇中國當代新聞傳媒從業人員的口述史,在全面審查時代下,他們無一例外地經歷了越來越不自由的從業狀態。

目录:
一、從禁令到法律,不斷進化的審查1、從禁令開始(1)綜合性新聞網絡媒體編輯,從業經歷:6年。(2)日報財經記者,從業經歷:3年。(3)全國性綜合網媒文化記者,從業經驗:2年。2、內化為自我審查(4)時政期刊資深編輯,從業經歷:18年。(5)微信公眾號編輯,600萬訂閲量。從業經歷:6年。(6)週報國際新聞記者,從業經歷:3年。3、最根本的,是立法管控(7)全國性商業周刊記者,從業經歷:4年。(8)時政期刊資深編輯,從業經歷:18年。二、內容審查:從時政到娛樂,一套全方位的審查體制1、時政一直是最敏感的(9)時政期刊資深編輯,從業經歷:18年。2、經濟與商業,如今也不遑多讓(10)中央級紙媒經濟版記者,從業經驗:2年。(11)財經廣播電台,記者,從業經歷:6年。(12)全國性商業周刊,商業記者,從業經歷:4年。3、國際新聞不能影射(13)全國週報,記者,從業經歷:3年,國際記者。4、人物報導,處處禁忌(14)人物類雜誌,資深記者,從業經歷:8年。(15)時政人物雜誌,攝影記者,從業經歷:5年。5、文化娛樂新聞,都在走鋼絲(16)新聞類網站,記者,從業經歷:3年,歷史類。(17)全國週報,記者,從業經歷:10年以上,文化。(18)門戶網站,娛樂新聞編輯,從業經歷:10年。6、讀者互動,重重設限(19)綜合性新聞網絡媒體,編輯,從業經歷:6年。三、把新媒體全面管起來1、風聲鶴唳的微信公眾號(20)訂閲人數100萬以上的微信公眾號,從業經歷:2年,非虛構類內容編輯。(21)訂閲量600萬以上的微信公眾號,從業經歷:6年,都市話題編輯。2、新媒體新聞平台:「不生產內容,但要對內容負責」(22)互聯網新聞平台,項目經理,從業經歷:3年。3、只能「歌頌正能量」的短視頻(23)短視頻網站,視頻編輯,從業經歷:3年。


以前去新聞現場,都是過2、3天會收到禁令;後來在去現場的路上就會收到禁令,但還是會去把採訪做了,萬一之後還能發出來;但是現在根本不會去現場了,因為絕不可能有機會發出來。圖為2015年8月,天津大爆炸現場。攝:VCG/VCG via Getty Images

中國新聞媒體業正在經歷全面審查時代。

南方週末新年獻詞事件」發生的2013年,一切開始顯著變化。中國官方提出「輿論鬥爭」、「敢於亮劍」、「佔領網絡輿論上甘嶺」、「打贏新三十年的意識形態反擊戰」等極為罕見的全新「提法」,並同時展開打擊微博舊大V、扶植新大V、收編商業大佬、建立新黨媒2.0版等一系列互聯網治理,其背後反應了一整套全新的媒體與互聯網治理思路、治理邏輯與治理手段的劇變。

此後,2014年8月7日「微信十條」(《即時通信工具公眾信息服務發展管理暫行規定》)實施、2015年2月4日「賬號十條」(《互聯網用戶賬號名稱管理規定》)實施,2015年4月28日,「約談十條」(《互聯網新聞信息服務單位約談工作規定》)實施。這一系列條例被官媒稱為「三個十條」。

根據官媒報導,「微信十條」是「對以微信為代表的即時通信工具公眾信息服務進行了規範」;「賬號十條」是對「就賬號的名稱、頭像和簡介等,對互聯網企業、用戶的服務和使用行為進行了規範」;而「約談十條」則是「推動了約談工作的進一步程序化、規範化」。

更重要的,在新修訂的中國《國家安全法》中,網絡安全成為國家安全的重要組成部分。2015年7月,全國人大常委會通過了新《國家安全法》,第一次在立法中明確了「網絡空間主權」的概念。

同時,網絡安全也有了專項法律管制。2016年11月8日,全國人大審議通過了《網絡安全法》,並於2017年6月1日開始正式實施。2017年5月8日,新版《互聯網新聞信息服務管理規定》出台,同樣於2017年6月1日開始實施,此後一大批娛樂類賬號被依據新法規關停。

到2018年,在非政府組織「無國界記者」(RSF)公布的全球新聞自由指數中,總共180個受調查的國家和地區裏,中國大陸繼續位列榜單第176名,保持全球倒數第五。

所有這一切,固然都昭示了確切無疑的結果。然而,糟糕的國際新聞自由指數排行、層出不窮的條例與法律,固然能反映中國新聞控制的嚴厲,及其在世界中所處的位置。但數據與法律,卻不能讓更多人看到,在此種新聞與媒體環境下,中國大多數普通媒體從業人所經歷的日常。

本篇報導採訪了超過二十名中國媒體從業者,他們有的從事傳統媒體,有的在新媒體工作;有的從事時政經濟等「敏感」報導,有的則書寫娛樂文化等並不「敏感」的題材……出於對受訪者的保護,本篇報導不列出他們的名字與具體供職的媒體名稱。

這是一篇中國當代新聞傳媒從業人員的口述史,在全面審查時代下,他們無一例外地經歷了愈來愈不自由的從業狀態,他們所經歷的被審查的日常,有的公眾很熟悉,但更多的細節,卻可能讓人相當陌生。

2018年,在非政府組織「無國界記者」(RSF)公布的全球新聞自由指數中,總共180個受調查的國家和地區裏,中國大陸繼續位列榜單第176名,保持全球倒數第五。攝:Wang Zhao/AFP/Getty Images

全面審查時代:中國媒體人正在經歷什麼?

$
0
0
来源:https://theinitium.com/article/20180910-mainland-censorship-journalist-in-china/

特約撰稿人:江雁南,獨立記者,自由撰稿人,發自香港,2018-09-10
中國新聞媒體業正在經歷全面審查時代。這是一篇中國當代新聞傳媒從業人員的口述史,在全面審查時代下,他們無一例外地經歷了越來越不自由的從業狀態。
以前去新聞現場,都是過2、3天會收到禁令;後來在去現場的路上就會收到禁令,但還是會去把採訪做了,萬一之後還能發出來;但是現在根本不會去現場了,因為絕不可能有機會發出來。圖為2015年8月,天津大爆炸現場。攝:VCG/VCG via Getty Images
目录:
一、從禁令到法律,不斷進化的審查 1、從禁令開始(1)綜合性新聞網絡媒體編輯,從業經歷:6年。(2)日報財經記者,從業經歷:3年。(3)全國性綜合網媒文化記者,從業經驗:2年。 2、內化為自我審查(4)時政期刊資深編輯,從業經歷:18年。(5)微信公眾號編輯,600萬訂閲量。從業經歷:6年。(6)週報國際新聞記者,從業經歷:3年。 3、最根本的,是立法管控(7)全國性商業周刊記者,從業經歷:4年。(8)時政期刊資深編輯,從業經歷:18年。二、內容審查:從時政到娛樂,一套全方位的審查體制 1、時政一直是最敏感的9)時政期刊資深編輯,從業經歷:18年。 2、經濟與商業,如今也不遑多讓(10)中央級紙媒經濟版記者,從業經驗:2年。(11)財經廣播電台,記者,從業經歷:6年。(12)全國性商業周刊,商業記者,從業經歷:4年。 3、國際新聞不能影射(13)全國週報,記者,從業經歷:3年,國際記者。 4、人物報導,處處禁忌(14)人物類雜誌,資深記者,從業經歷:8年。(15)時政人物雜誌,攝影記者,從業經歷:5年。 5、文化娛樂新聞,都在走鋼絲(16)新聞類網站,記者,從業經歷:3年,歷史類。(17)全國週報,記者,從業經歷:10年以上,文化。(18)門戶網站,娛樂新聞編輯,從業經歷:10年。 6、讀者互動,重重設限19)綜合性新聞網絡媒體,編輯,從業經歷:6年。三、把新媒體全面管起來 1、風聲鶴唳的微信公眾號(20)訂閲人數100萬以上的微信公眾號,從業經歷:2年,非虛構類內容編輯。(21)訂閲量600萬以上的微信公眾號,從業經歷:6年,都市話題編輯。 2、新媒體新聞平台:「不生產內容,但要對內容負責」(22)互聯網新聞平台,項目經理,從業經歷:3年。 3、只能「歌頌正能量」的短視頻23)短視頻網站,視頻編輯,從業經歷:3年。

南方週末新年獻詞事件」發生的2013年,一切開始顯著變化。中國官方提出「輿論鬥爭」、「敢於亮劍」、「佔領網絡輿論上甘嶺」、「打贏新三十年的意識形態反擊戰」等極為罕見的全新「提法」,並同時展開打擊微博舊大V、扶植新大V、收編商業大佬、建立新黨媒2.0版等一系列互聯網治理其背後反應了一整套全新的媒體與互聯網治理思路、治理邏輯與治理手段的劇變。
此後,2014年8月7日「微信十條」(《即時通信工具公眾信息服務發展管理暫行規定》)實施、2015年2月4日「賬號十條」(《互聯網用戶賬號名稱管理規定》)實施,2015年4月28日,「約談十條」(《互聯網新聞信息服務單位約談工作規定》)實施。這一系列條例被官媒稱為「三個十條」。
根據官媒報導,「微信十條」是「對以微信為代表的即時通信工具公眾信息服務進行了規範」;「賬號十條」是對「就賬號的名稱、頭像和簡介等,對互聯網企業、用戶的服務和使用行為進行了規範」;而「約談十條」則是「推動了約談工作的進一步程序化、規範化」。
更重要的,在新修訂的中國《國家安全法》中,網絡安全成為國家安全的重要組成部分。2015年7月,全國人大常委會通過了新《國家安全法》,第一次在立法中明確了「網絡空間主權」的概念。
同時,網絡安全也有了專項法律管制。2016年11月8日,全國人大審議通過了《網絡安全法》,並於2017年6月1日開始正式實施。2017年5月8日,新版《互聯網新聞信息服務管理規定》出台,同樣於2017年6月1日開始實施,此後一大批娛樂類賬號被依據新法規關停。
到2018年,在非政府組織「無國界記者」(RSF)公布的全球新聞自由指數中,總共180個受調查的國家和地區裏,中國大陸繼續位列榜單第176名,保持全球倒數第五。
所有這一切,固然都昭示了確切無疑的結果。然而,糟糕的國際新聞自由指數排行、層出不窮的條例與法律,固然能反映中國新聞控制的嚴厲,及其在世界中所處的位置。但數據與法律,卻不能讓更多人看到,在此種新聞與媒體環境下,中國大多數普通媒體從業人所經歷的日常。
本篇報導採訪了超過二十名中國媒體從業者,他們有的從事傳統媒體,有的在新媒體工作;有的從事時政經濟等「敏感」報導,有的則書寫娛樂文化等並不「敏感」的題材……出於對受訪者的保護,本篇報導不列出他們的名字與具體供職的媒體名稱。
這是一篇中國當代新聞傳媒從業人員的口述史,在全面審查時代下,他們無一例外地經歷了愈來愈不自由的從業狀態,他們所經歷的被審查的日常,有的公眾很熟悉,但更多的細節,卻可能讓人相當陌生。

2018年,在非政府組織「無國界記者」(RSF)公布的全球新聞自由指數中,總共180個受調查的國家和地區裏,中國大陸繼續位列榜單第176名,保持全球倒數第五。攝:Wang Zhao/AFP/Getty Images
Viewing all 1645 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>