SSL初级指南

最新推荐文章于 2024-09-19 09:51:43 发布

theodoresi

最新推荐文章于 2024-09-19 09:51:43 发布

阅读量352

点赞数 1

分类专栏：加密文章标签： SSL 加密

本文链接：https://blog.csdn.net/theodoresi/article/details/94785858

版权

加密专栏收录该内容

1 篇文章 0 订阅

订阅专栏

不知道你是否注意过，我们在Outlook等客户端设置邮箱时，对于发送(SMTP)或者接收(POP或者IMAP)邮件的协议，都有两个甚至三个端口可以选择。例如对于SMTP，我们既可以选择传统的25端口，也可以选择465/994端口。下图是163邮箱的设置：

在这里插入图片描述

那么使用不同的端口有什么区别呢？其实，他们的区别就在于是否使用SSL协议对上述应用层传输的数据进行加密。由于这些邮件传输协议都是明文传输的，因此如果有人别有用心，他们就可以对你的通信内容进行拦截获取。但是如果数据被加密过了，那么即使他们进行了抓包，也只会看到一团乱码，不知所云。

事实上SSL不仅可以进行邮件加密，它作为一种介于应用层(如HTTP，SMTP)和传输层(如TCP)之间的协议，可以与各种应用层协议结合，为之提供数据加密。可以说SSL协议是当今网络安全的一块基石。既然它这么重要，我们就来好好了解一下它吧！

SSL的前世今生

要谈起SSL，我们就不得不谈谈伟大的网景(Netscape)公司。网景公司的Navigator浏览器曾经在上世纪九十年代占据了高达90%的市场份额，简直让今天的Chrome都要汗颜。(可惜在第一次浏览器战争中，Navigator不敌微软的IE浏览器，败下阵来)。网景公司还发明了驱动着当今几乎所有网站的JavaScript，可谓光芒万丈。而其另外一项伟大的发明就是SSL协议，它为我们今天能够安全地使用互联网提供了保障。

最初SSL协议被应用在网景自家的浏览器Navigator中，目的是为用户提供安全的网页浏览服务。上世纪末，互联网的发展催生了越来越多的网络应用，而许多应用场景都涉及私密或敏感信息，例如用户的信用卡信息、账户密码等。因为HTTP协议中数据是以明文传递的，这些内容面临着被窃取的风险。

你可以想象HTTP协议是一根塑料软管，黑客只需在管子上扎个小洞，里面的信息就源源不断地奔涌而出。而SSL协议则是给这根塑料软管外套上了一层铜墙铁壁，任凭千扎万穿，也无动于衷，这有效地防止了信息泄露。

当然，正如每位拯救世界的超级英雄，SSL协议的成长之路也不是一帆风顺的。它的1.0版本甚至从来没有公开发布过，因为漏洞过多。直至1996年的SSL 3.0协议才基本完善，但是也很快就被TLS(Transport Layer Security)协议所取代，写入了RFC 2246。在计算机网络领域，这样的故事似乎屡见不鲜。许多协议最开始都是某个公司的商业产品，而他们被广泛应用和接受后，也就演变为事实标准。这个时候就需要对他们进行标准化，提供“编制”，写入RFC。

TLS协议建立在SSL 3.0的基础上，所以我们也时常会看到SSL/TLS这样的描述，我们可以认为两者是等价的(事实上我们现在使用的都是TLS协议了)。尽管SSL协议已经成为“过往云烟”，但是由于先入为主，人们更多的时候还是习惯用SSL而不是TLS，因此后面我也将延续这一传统。

SSL协议原理

上面我们提到，SSL协议位于应用层和传输层之间，为各类应用程序提供加密。其实这样说并不严谨，因为SSL协议到底属于哪一层，处于一种公说公有理，婆说婆有理的灰色地带，有人说属于表示层，也有人认为属于会话层。事实上网络分层只是一种参考，并不是科学理论，所以有时候没有必要锱铢必较。对于SSL这样为弥补前人缺陷后来“加塞”进来的协议更是如此。我们只要知道它使用了TCP协议，并且为传统的应用层协议提供加密服务即可。
在这里插入图片描述

如果感到快乐你就握握手

如果你学习过TCP协议，那你对握手(handshake）的概念应该不陌生。正如人类在见面后需要握手，从而进行业务协商，两台需要通信的计算机也需要通过握手来对后续的交流过程制定规范。使用SSL协议进行通信的双方需要通过握手确定诸如使用什么加密算法，用来加密实际数据的共享秘钥是什么等重要事宜。

具体的握手过程如下：

Client发送Client Hello。凡是一段关系的建立，都要有主动的一方。Client首先向Server发送Hello，告知使用的TLS协议版本，可供服务器选择的加密算法组合(Cipher Suite)，以及一个随机数等信息。
Server发送Server Hello。Server对Client做出相应，并告知Client其所选择的加密算法组合，以及一个随机数。
Server发送Certificate(包括自己的公钥)。服务器向客户端发送它的证书，供Client认证它的真实性，而公钥会被用来对真正的秘钥进行加密。
Server发送Server Hello Done。
Client Key Exchange。Client确认Server的真实身份后，生成共享秘钥(Premaster secret)，并用Server提供的公钥进行加密并发送。这里使用了非对称加密技术。因为双方目前通信的链路是不安全的，当然不能明目张胆的告诉对方“我们一会用1234567作为我们后面的秘钥吧”！因此，需要Client用Server提供的公钥对其加密后告诉Server，“我们一会用sf8df823f@fw32r98FD#!23@” 作为我们的秘钥吧。而Server拿到这一串乱码后可以用只有它自己知道的私钥解密，得到真实秘钥，如1234567，而任何中间人只能抓耳挠腮，不知所措了。
现在双方都得知了共享秘钥，于是他们进行下一步，Change Cipher Spec。在这一步，他们利用共享秘钥，以及客户端和服务器端生成的随机数，得出真正用来进行数据加密的Session key，然后通知对方，“接下来我们就要切换到对称加密方式，用Session key加密数据咯”。握手过程结束。
上述过程可以用下图的场景来说明。

在这里插入图片描述

嘿，我们安全了

随后，双方就开始用共享秘钥进行对称加密，从而进行实际的数据传输了。之所以要使用对称加密，主要是出于性能的考虑。非对称加密用来交换共享秘钥这样的数据还行，如果对大量实际数据加密就会让Client和Server都“感觉身体被掏空”。

为了对上面的内容有个更加直观的认识，我们这里就举个栗子，用SMTP协议的通信情况来验证SSL协议的功效。

没有对比就没有伤害，我们先来看看青铜的操作吧。首先用普通非加密的SMTP协议进行邮件发送。代码片段如下：

server = smtplib.SMTP('smtp.163.com', 25)
server.login(from_addr, password)
server.send_message(msg)

用Wireshark进行抓包以后，我们可以看到邮件内容一览无余(倒数第四行是邮件标题，展开的话还可以看到邮件正文，这里太懒就没有截图了)。如果看不清，可以右键，在新窗口打开图片。

在这里插入图片描述

那么我们现在为塑料软管加上一层钢铁战甲吧！

server = smtplib.SMTP_SSL('smtp.163.com', 465)
server.login(from_addr, password)
server.send_message(msg)

在这里插入图片描述

我们可以看到这里使用了TLS 1.2协议，而传输的数据都经过加密了。

接下来我们就看看其中具体的信息吧！

Client Hello：我们可以看到Client向Server提供了31种加密组合。Server可能处于安全性和性能的综合考虑，对Client所支持的加密组合有一个优先级排序，因此Client需要告知自己所支持的所有方式。
在这里插入图片描述
Server Hello：Server 选择了其中一种，RSA就是用来传递共享秘钥的非对称加密算法，而AES则是后续使用的对称加密算法。

在这里插入图片描述

随后Server向Client发送了自己的证书和公钥：

在这里插入图片描述
而Client则使用该公钥把共享秘钥进行加密，然后发送给Server：

在这里插入图片描述
Server对之解密后就会得到共享秘钥，然后就可以开始和Client安全地进行数据交换了。

总结

正如计算机科学家David Wheller所说，“All problems in computer science can be solved by another level of indirection”。当原有的应用层协议无法满足新的安全需求时，SSL应运而生。它通过“加塞”的形式，在不需对原有的HTTP协议和其他基础设施进行修改的情况下，为我们提供了更加安全的网络服务。而由于其通用性，SSL及其后继者TLS协议也在其他更为广阔的天地大展拳脚。

希望这篇文章对你有所帮助，使你对SSL协议有了一定的了解。本文主要介绍了SSL的起源，它的握手过程，并通过一个示例验证了SSL对SMTP服务的加密。我的下一篇文章依然是关于SSL，我将带你回到它“梦想开始的地方”，看SSL和HTTP的“爱情结晶”HTTPS如何为我们提供了安全的互联网浏览体验。