Go 实现 TLS 通信 (1, TLS简介)

本系列文章包含以下内容

  1. 单向TLS不认证,客户端不检查服务端证书的有效性
  2. 单向TLS认证,客户端检查服务端证书的有效性
  3. 双向TLS认证,服务端验证客户端证书的有效性
  4. 升级协议,在通信过程中升级成TLS通信

本系列文章中大写C统一表示客户端,大写S表示服务器端。

简介

TLS(Transport layer layer)是一种安全协议,目的为互联网通信提供安全及完整性保障

定义摘自维基百科。

完整性保障很容易理解,C(客户端)与S(服务器端)通信,客户端发出信息[转10000给张三],经过网络传输后,由于网络丢包变成了[转100块给张三],客户端估计会被张三揍哭。因此服务端(收到信息的一方)需要保证收到的信息确实一丝一毫都没变。这就是完整性。
保证完整性通常通过哈希值来实现。比如我们可以设计一种弱鸡的算法,计算字数的个数作为哈希,那么信息变成了[转10000块给张三,10],其中10就是哈希值,那么如果服务端收到的信息是[转100块给张三,10],服务端检查到哈希值不正确就知道消息在传输过程中发生了错误。然而如果信息变成了[转20000块钱给张三,10],这个弱鸡算法就不能帮助服务器检查到这个错误。因此哈希算法基础的要求就是碰撞(给定信息1,构造另一段信息2,使得2的哈希值与1相等)的难度。

什么是安全性呢?
安全性包含两个方面,假定C是你,S是你女朋友。SC发信息[给我打10000块]。C的第一反应是什么?是确认S真的是你女朋友。因此安全性的第一个方面是确定双方的通信身份。
假如C想给S回复[今晚XXXX不可描述],C需要确认什么?一定是这段信息没人在窃听。这就是安全性的第二个方面。

如何解决第一个问题:C和S如何确定你真的是你? 在CS互为男女朋友的情况下,C可以和S约定一下暗号,比如天王盖地虎小鸡炖蘑菇,在每次通信之前先对一下暗号。
如果只有C和S通信,约定暗号自然是可行的。但是如果C或者S不只一个呢。比如有C1,C2,那么如果用同样的暗号,C2知道暗号是什么后就可以欺骗S说自己是C1。如果都约定不同的暗号,那么假如有C1,C2,... ,C10000,那么就有S就需要记住10000个暗号,并且每新来一个C,就需要多记住一个暗号。
S表示,太累了。“给你们一段我的手写体吧,以后你们验证笔迹一样就能确定我是我了”
"笔迹,太容易伪造了吧!", 数学表示,"是时候看我展现真正的实力了!"
困难问题在数学中通常是"讨厌"的存在,数学家们会穷尽毕生去解决。密码学却是数学中的一个有趣的分支,它反其道而行之,核心是去证明某个问题是困难的。什么是困难问题?民科定义就是在现有的公开的数学下,要解决这个问题得花成百上千年。专业术语表达是NP问题,或者从安全意义上说解决这个问题获得的利益小于解决问题付出的代价

"嘿嘿嘿,这道题你们做不出来,但是我有后门,我会做"。加密算法站了出来。

先用非对称加密(加密密钥和解密密钥不相同)来解决你真的是你这个问题。
在非对称算法中,有两个密钥,一个是公钥,一个私钥。通常情况下私钥自己留着,公钥给对外公开。私钥加密后的信息,公钥可以解密还原内容。由公钥以及已经发生过的加密解密信息推算出私钥是一个困难问题
我们来尝试构造一个弱鸡的非对称算法,并假装它是一个困难问题。
这个算法是这样的,假定我们发出的信息只能是[1,2,3,4,5,...,10], 公钥是10。并且我们自己保留私钥7。加密算法是 (x+7)%17, 解密算法是 (x+10)%17。我们假装通过10和已经发生过的加解密的过程无法推算出私钥7。

由于((x+7)%17+10)%17 = x, 比如对信息5加密,用私钥7加密5+7=12,用公钥10解密(12+10)%17=22%17=5, 就可以将信息还原。
有了这个算法,C需要验证S的身份只需要说一句,“嘿,6加密后的数据是什么”,S算了以下回复,“13”,客户端用公钥运算(13+10)%17果然是6,就可以快乐的回应,“来啦,老弟!”

在上面的场景中,有了非对称密钥算法,S可以换成说,“我的公钥放在网上了,你们自己去拿,拿好以后,以后验证我私钥加密过的信息解密后就确认我是我了”。(注:这里不谈及CA及信任链,默认C拿到证书后可以确认这个证书确实是S的证书)

如何解决第二个问题:C和S如何确保通信没有被窃听,或者即使被窃听也不能听懂内容究竟是什么?
在互联网环境下,保证第一条是不可能的,公开网络中任何一个节点都有可能被抓包解析。非对称加密通过私钥加密信息在网上传输可以应对这个问题。但这样做有两个缺点:一个是非对称加密通常相对比较慢,第二个问题是虽说非对称加密是安全的,但架不住老是拿同样的公钥私钥来传输大量的信息,这样做会破坏它的安全性。因此,通常会选择使用用公钥沟通,得出一个在一次对话过程中使用的对称加密(公钥和私钥相同)的密钥来(密钥交换协议),并在之后的通信中使用对称加密算法来加密传输内容,来保证传输过程的安全性。

对称加密容易理解,这里不做多谈。

注意:以上简介均非规范描述,只是以简化的形式来描述网络通信面临的安全问题以及解决的方法。
简介中提到的对称加密算法,非对称加密算法,和没有提及的如何在一次会话中采用安全的协议来沟通出对称密钥,均可以在维基百科上找到相应的介绍。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343