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

来源: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

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



如您所知,"对内和对外"的态度在很多时候是有区别的,也是为什么人们普遍对内幕消息的兴趣远高于宣传稿。但是对于谷歌来说,这里的"区别"简直就是天壤之别,他们为什么要掩盖[对于一家公司来说单纯的赚钱兴趣]?我们似乎能闻到一股奇怪的味道,它可能远非"怕丢人"这么简单。本文是 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 没有对其工作人员说明全部,至少此前已经有明确报道,在该项目计划被泄露之后谷歌内部紧急维稳封锁了相关资料;其次,谷歌"背后的人"也很可能没有对谷歌说明全部,这部分不做推测。但现在您至少可以了解到一个大概了。◾️

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





中国广州——微信已经成为在中国生活不可或缺的一部分。作为中国对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。放弃隐私和言论自由以换取便利,这不是我愿意做的交易。

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



中国正在对其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 版本才支持它。