翻越防火长城,你可以到达世界上的每一个角落。
Across the Great Firewall, you can reach every corner in the world.
为何我选择不依赖微信生活
【聚焦】中国无死角“数字独裁”体系下的模范公民
ABC 驻华记者 Matthew Carney
听起来,一个反乌托邦的未来已经在中国发生。而且这正在创造或是破坏着人们的生活。
中国共产党称其为"社会信用评级",并表示这套系统将在2020年前完全投入使用。
一份中共官方规划纲要称,在几年内,该系统将"使守信者处处受益、失信者寸步难行"。
社会信用就好比中国14亿公民的个人记分卡。
在一个已经实施的试点项目中,每位公民都被分配到800分内的一个分数。其他项目中是900分。
全文:http://www.abc.net.au/chinese/2018-09-18/china-social-credit-leave-no-dark-corner/10264922
媒體人、淘寶店主、畢業生、普通網民......自由如何被閹割?
「不知道有多少人在做着幻夢,又不知道有多少人從這可怖的幻夢中尖叫着醒來。這個國家的人心在逐漸沉下去,而上位者還泡在人血裏不斷上浮。」
扫盲 HTTPS 和 SSL/TLS 协议[4]:历史版本的演变及 Record 协议的细节
前些天(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)
"类型"字段是个枚举值,协议允许的有效值如下:
| 十进制 | 十六进制 | 含义 | 备注 |
|---|---|---|---|
| 0x14 | 20 | ChangeCipherSpec(切换到加密方式) | TLS 1.3 废弃 |
| 0x15 | 21 | Alert(告警) | |
| 0x16 | 22 | Handshake(握手) | |
| 0x17 | 23 | Application(应用层数据) | |
| 0x18 | 24 | Heartbeat(心跳) | 始于 TLS 1.3 |
◇版本(version)
"版本"字段含两个字节,分别表示:主版本号 和 次版本号。有效值如下:
| 主版本号 | 次版本号 | 含义 |
|---|---|---|
| 0x2 | 0x0 | SSL 2.0 |
| 0x3 | 0x0 | SSL 3.0 |
| 0x3 | 0x1 | TLS 1.0 |
| 0x3 | 0x2 | TLS 1.1 |
| 0x3 | 0x3 | TLS 1.2 |
◇长度(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.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 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 表示通讯出现【不稳定】的情况(这种"不稳定"通常是【可恢复】滴)如果不对劲的情况属于 Warning,通讯可能会继续也可能会断开;如果不对劲的情况属于 Fatal,通讯会在发送 Alert 之后立即断开。
Fatal 表示通讯出现【不可靠】的情况(比如:证书失效、数据被篡改。这种"不可靠"通常是【不可恢复】滴)
这种类型的 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
「你讓一個最誠實的人寫下六行字交給我,我就能找到把他吊死的罪狀。」
— 紅衣主教李希留(Richelieu),1641年
每個人都該知道的基本資安概念
方法1:在電郵信箱上採用雙重認證機制
方法2:將電腦硬碟內容加密

FileVault 完整磁碟加密(FileVault 2)使用 XTS-AES-128 加密搭配 256 位元密鑰,防止他人未經授權存取您啟動磁碟上的資訊。support.apple.com
方法3:在手機上使用密碼保護
1234 9999 1111 3333 0000 5555 1212 6666 7777 1122 1004 1313 2000 8888 4444 4321 2222 2001 6969 1010
譯按:原文所描述的其實是手機主人「萬一被逮捕」的情境,而如前文所述,美國法律雖然保障不說密碼的自由,但可以強制用戶以指紋當場開機;所以如果透過立即關機,讓手機變成「只能用密碼開啟」的狀態,可以拖延官方取得手機內容的時間。
如果你不是在美國,這一招就不一定有效,但或許在某些情境下還是可以參考使用。
方法4:在不同的服務上使用不同的密碼

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



方法6:記得,瀏覽器的「無痕模式」並不夠安全
- 網路服務商
- 學校、公司、或是任何上網場所的網路管理員;
- Google或任何其他瀏覽器的出品廠商。
方法7:使用「Tor」進行私密瀏覽
譯按:Tor是用來為通訊內容加密的工具,最好搭配同樣安全的瀏覽器使用。iOS版已經將兩者整合在一起,而Android版則可以搭配Orfox瀏覽器。
Tor Browser will block browser plugins such as Flash, RealPlayer, Quicktime, and others: they can be manipulated into…www.torproject.org




5. 確認安全連線是否成功
方法8:使用私密搜尋工具


Edit descriptionamzn.to
編按:上述這本書的中文版為《隱形帝國:誰控制大數據,誰就控制你的世界》,由如果出版社出版。但由於原書是在2016年出版,所以其中的部分工具或觀念可能不是最新的,但大多數的資安原則應該還是不變的。
書名:隱形帝國:誰控制大數據,誰就控制你的世界,原文名稱:Data and Goliath: The Hidden Battles to Collect Your Data and Control Your…www.books.com.tw




