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



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

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

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

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

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

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

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

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


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






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

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

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

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


文章目录
★名词解释
★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 版本才支持它。

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

来源微信号:xiaoyanggc , 笑央 


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

 

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

 


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

 

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


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


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


 

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

 

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

 


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

 

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

 

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

 

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

 


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


 

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



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


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


 

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



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


 

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


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


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

 

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


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


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

 

 

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


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


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



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

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





中国网络安全监管机构已证实因为澳大利亚广播公司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付费电视频道向澳大利亚观众播出。

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



每個人都有的電子郵件信箱,是最容易被忽視的個資罩門;如果信箱被攻破,入侵者不僅可以閱讀通訊內容,還可以重設你幾乎所有帳號的密碼。千萬別再覺得「反正我的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原文出處