HTTPs SSL CA

一张图(燕姐课上讲过,必考)对称密钥(DES/DES3/AES),非对称密钥(RSA公钥加密,只有私钥能解密。私钥可以当作签名使用,lhh,hsj不懂请自行百度一下)


签名的流程示意图:

1. CA建立,并颁发给自己根证书。
2. CA与浏览器开发者联系,将自己根证书绑定浏览器。
3. 网站服务器产生自己的公私钥,并把自己信息和公钥等信息作为申请文件,请求 CA颁发 证书
4. CA核实申请者信息,用私钥(还是根证书呢?)给申请文件签名,并颁发给网站服务器。
5. 网站服务器拿到签名的证书,把它配置到 Apache等自己的服务器上。
6. 客户端浏览网站时,网站服务器将证书发送给客户端,客户端验证 CA的签名。


以下是整个客户—服务器验证流程(耐心看):


假设A要想B发送消息,A会先计算出消息的消息摘要,然后使用自己的私钥加密这段摘要加密,最后将加密后的消息摘要和消息一起发送给B,被加密的消息摘要就是“签名”。

B收到消息后,也会使用和A相同的方法提取消息摘要,然后使用A的公钥解密A发送的来签名,并与自己计算出来的消息摘要进行比较。如果相同则说明消息是A发送给B的,同时,A也无法否认自己发送消息给B的事实。

数字签名的作用是保证数据完整性,机密性和发送方角色的不可抵赖性。

如果甲想给乙发一个安全的保密的数据,那么应该甲乙各自有一对公私钥,甲先用乙的公钥加密这段

数据,再用自己的私钥加密这段加密后的数据,最后再发给乙。这样确保了内容即不会被读取,也不会被篡改。

 二、证书及CA介绍

公钥、私钥、证书

一个公钥对应一个私钥。

密钥对中,让大家都知道的是公钥,不告诉大家,只有自己知道的,是私钥。

为什么需要用证书来替代公钥?

答:在上面的加密签名等过程中,我们都忽略了一点,那就是如何确保我们获取的公钥是正确的。第三者很容易制作一个公钥来冒充我们的交互目标,我们没法凭借这个公钥来确认对方的身份。在这样的情况下,证书就诞生了,证书是一个包装了公钥的实体,他里面包含了公钥,机构名称,证书有效期,ca签名等信息。这样我们获取证书后,就可以通过证书里面对机构的描述来确认对方的身份。

证书中的ca是什么意思?

答:其实上面对证书的描述并没有完全解决我们提出的问题,第三者完全可能制作一个证书,而证书里的机构信息也是伪造的。那么ca就在这种情形下出现了。ca是证书颁发机构(certification authority)。ca是第三方的,为数不多的,可信赖的机构,我们可以在其官网上获取他的公钥,用他的公钥来解析ca签名,就能够唯一的验证这个证书是由这个ca机构颁发的。ca机构会维护自己的publickey库,比如公司“通联支付”去ca申请证书后,那第三者就无法再以“通联支付”的名字来申请证书了。那么也就能验证这个证书不是由第三者假冒的了。

Ca的分级认证模式

假设C证书信任A和B;然后A信任A1和A2;B信任B1和B2。则它们之间构成如下的一个树形关系(一个倒立的树)。

处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。而根证书自己证明自己,或者换句话说,根证书是不需要被证明的。

浏览器如何识别证书的有效性?

浏览器默认会导入当地比较大的ca机构签发的二级证书。当用户访问https网站时,浏览器通过ssl协议首先下载网站的证书,然后通过本地的ca二级证书对网站的证书进行验签。如果验签不通过,则一般都会出现警告弹窗。

证书和CA的出现,旨在解决公钥的准确性,进而确保RSA算法进行加密和签名的可靠性。

三、HTTPS详细介绍(重要:老师课上讲过的

https认证分为单向认证和双向认证,单向认证适用与互联网大众用户;双向认证适用与企业内部,集群内部。

单向认证:客户端无证书,客户端认证服务端发送过来的证书,从而认证服务端。后续通过ssl握手,建立对称加密通讯。

双向认证:客户端有证书,客户端认证服务器发送过来的证书,服务端认证客户端发送过来的证书,互相认证。后续通过ssl握手,建立对称加密通讯。

交互流程(一个加密通信过程的演化)

我们来看一个例子,现在假设“服务器”和“客户”要在网络上通信,并且他们打算使用RSA来对通信进行加密以保证谈话内容的安全。由于是使用RSA这种公钥密码体制,“服务器”需要对外发布公钥(算法不需要公布,RSA的算法大家都知道),自己留着私钥。“客户”通过某些途径拿到了“服务器”发布的公钥,客户并不知道私钥。“客户”具体是通过什么途径获取公钥的,我们后面再来说明,下面看一下双方如何进行保密的通信:

2.1 第一回合:

“客户”->“服务器”:你好

“服务器”->“客户”:你好,我是服务器 “客户”->“服务器”:我的账号和密码是...

因为消息是在网络上传输的,有人可以冒充自己是“服务器”来向客户发送信息。例如上面的消息可以被黑客截获如下:

“客户”->“黑客”:你好 // 黑客在“客户”和“服务器”之间的某个路由器上截获“客户”发给服务器的信息,然后自己冒充“服务器” “黑客”->“客户”:你好,我是服务器

因此“客户”在接到消息后,并不能肯定这个消息就是由“服务器”发出的,某些“黑客”也可以冒充“服务器”发出这个消息。如何确定信息是由“服务器”发过来的呢?有一个解决方法,因为只有服务器有私钥,所以如果只要能够确认对方有私钥,那么对方就是“服务器”。因此通信过程可以改进为如下:

2.2 第二回合:

“客户”->“服务器”:你好

“服务器”->“客户”:你好,我是服务器 “客户”->“服务器”:向我证明你就是服务器

“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

// 注意这里约定一下,{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密,后面的示例中都用这种表示方式,例如上面的 {你好,我是服务器}[私钥|RSA] 就表示用私钥对“你好,我是服务器”进行加密后的结果。

为了向“客户”证明自己是“服务器”, “服务器”把一个字符串用自己的私钥加密,把明文和加密后的密文一起发给“客户”。对于这里的例子来说,就是把字符串 “你好,我是服务器”和这个字符串用私钥加密后的内容 {你好,我是服务器}[私钥|RSA] 发给客户。 “客户”收到信息后,她用自己持有的公钥解密密文,和明文进行对比,如果一致,说明信息的确是由服务器发过来的。也就是说“客户”把 {你好,我是服务器}[私钥|RSA] 这个内容用公钥进行解密,然后和“你好,我是服务器”对比。因为由“服务器”用私钥加密后的内容,由并且只能由公钥进行解密,私钥只有“服务器”持有,所以如果解密出来的内容是能够对得上的,那说明信息一定是从“服务器”发过来的。

假设“黑客”想冒充“服务器”:

“黑客”->“客户”:你好,我是服务器 “客户”->“黑客”:向我证明你就是服务器

“黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[???|RSA] //这里黑客无法冒充,因为他不知道私钥,无法用私钥加密某个字符串后发送给客户去验证。 “客户”->“黑客”:我的账号和密码是...

由于“黑客”没有“服务器”的私钥,因此它发送过去的内容,“客户”是无法通过服务器的公钥解密的,因此可以认定对方是个冒牌货!

到这里为止,“客户”就可以确认“服务器”的身份了,可以放心和“服务器”进行通信,但是这里有一个问题,通信的内容在网络上还是无法保密。为什么无法保密呢?通信过程不是可以用公钥、私钥加密吗?其实用RSA的私钥和公钥是不行的,我们来具体分析下过程,看下面的演示:

2.3 第三回合:

“客户”->“服务器”:你好

“服务器”->“客户”:你好,我是服务器 “客户”->“服务器”:向我证明你就是服务器

“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[公钥|RSA]

“服务器”->“客户”:{你的余额是100元}[私钥|RSA]

注意上面的的信息 {你的余额是100元}[私钥],这个是“服务器”用私钥加密后的内容,但是我们之前说了,公钥是发布出去的,因此所有的人都知道公钥,所以除了“客户”,其它的人也可以用公钥对{你的余额是100元}[私钥]进行解密。所以如果“服务器”用私钥加密发给“客户”,这个信息是无法保密的,因为只要有公钥就可以解密这内容。然而“服务器”也不能用公钥对发送的内容进行加密,因为“客户”没有私钥,发送给“客户”也解密不了。 这样问题就又来了,那又如何解决呢?在实际的应用过程,一般是通过引入对称加密来解决这个问题,看下面的演示:


2.4 第四回合:

“客户”->“服务器”:你好

“服务器”->“客户”:你好,我是服务器 “客户”->“服务器”:向我证明你就是服务器

“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

“客户”->“服务器”:{我们后面的通信过程,用对称加密来进行,这里是对称加密算法和密钥}[公钥|RSA] //蓝色字体的部分是对称加密的算法和密钥的具体内容,客户把它们发送给服务器。

“服务器”->“客户”:{OK,收到!}[密钥|对称加密算法]

“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]

“服务器”->“客户”:{你的余额是100元}[密钥|对称加密算法]

在上面的通信过程中,“客户”在确认了“服务器”的身份后,“客户”自己选择一个对称加密算法和一个密钥,把这个对称加密算法和密钥一起用公钥加密后发送给“服务器”。注意,由于对称加密算法和密钥是用公钥加密的,就算这个加密后的内容被“黑客”截获了,由于没有私钥,“黑客”也无从知道对称加密算法和密钥的内容。 由于是用公钥加密的,只有私钥能够解密,这样就可以保证只有服务器可以知道对称加密算法和密钥,而其它人不可能知道(这个对称加密算法和密钥是“客户”自己选择的,所以“客户”自己当然知道如何解密加密)。这样“服务器”和“客户”就可以用对称加密算法和密钥来加密通信的内容了。

但是这里还留有一个问题,在最开始我们就说过,“服务器”要对外发布公钥,那“服务器”如何把公钥发送给“客户”呢?我们第一反应可能会想到以下的两个方法: a)把公钥放到互联网的某个地方的一个下载地址,事先给“客户”去下载。 b)每次和“客户”开始通信时,“服务器”把公钥发给“客户”。 但是这个两个方法都有一定的问题,

对于a)方法,“客户”无法确定这个下载地址是不是“服务器”发布的,你凭什么就相信这个地址下载的东西就是“服务器”发布的而不是别人伪造的呢,万一下载到一个假的怎么办?另外要所有的“客户”都在通信前事先去下载公钥也很不现实。

对于b)方法,也有问题,因为任何人都可以自己生成一对公钥和私钥,他只要向“客户”发送他自己的私钥就可以冒充“服务器”了。示意如下:

“客户”->“黑客”:你好 //黑客截获“客户”发给“服务器”的消息

“黑客”->“客户”:你好,我是服务器,这个是我的公钥 //黑客自己生成一对公钥和私钥,把公钥发给“客户”,自己保留私钥 “客户”->“黑客”:向我证明你就是服务器

“黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[黑客自己的私钥|RSA] //客户收到“黑客”用私钥加密的信息后,是可以用“黑客”发给自己的公钥解密的,从而会误认为“黑客”是“服务器”

因此“黑客”只需要自己生成一对公钥和私钥,然后把公钥发送给“客户”,自己保留私钥,这样由于“客户”可以用黑客的公钥解密黑客的私钥加密的内容,“客户”就会相信“黑客”是“服务器”,从而导致了安全问题。这里问题的根源就在于,大家都可以生成公钥、私钥对,无法确认公钥对到底是谁的。 如果能够确定公钥到底是谁的,就不会有这个问题了。例如,如果收到“黑客”冒充“服务器”发过来的公钥,经过某种检查,如果能够发现这个

公钥不是“服务器”的就好了。

为了解决这个问题,数字证书出现了,它可以解决我们上面的问题。

这里先只需要搞清楚一点,数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的,或者证书可以用来确认对方的身份。也就是说,我们拿到一个数字证书,我们可以判断出这个数字证书到底是谁的。至于是如何判断的,后面会在详细讨论数字证书时详细解释。现在把前面的通信过程使用数字证书修改为如下:

2.5 第五回合:

“客户”->“服务器”:你好

“服务器”->“客户”:你好,我是服务器,这里是我的数字证书 //这里用证书代替了公钥

“客户”->“服务器”:向我证明你就是服务器

“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

注意,上面第二次通信,“服务器”把自己的证书发给了“客户”,而不是发送公钥。“客户”可以根据证书校验这个证书到底是不是“服务器”的,也就是能校验这个证书的所有者是不是“服务器”,从而确认这个证书中的公钥的确是“服务器”的。后面的过程和以前是一样,“客户”让“服务器”证明自己的身份,“服务器”用私钥加密一段内容连同明文一起发给“客户”,“客户”把加密内容用数字证书中的公钥解密后和明文对比,如果一致,那么对方就确实是“服务器”,然后双方协商一个对称加密来保证通信过程的安全。到这里,整个过程就完整了,我们回顾一下:

2.6 完整过程:

step1: “客户”向服务端发送一个通信请求 “客户”->“服务器”:你好

step2: “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息,私钥由“服务器”持有

“服务器”->“客户”:你好,我是服务器,这里是我的数字证书

step3: “客户”收到“服务器”的证书后,它会去验证这个数字证书到底是不是“服务器”的,数字证书有没有什么问题,数字证书如果检查没有问题,就说明数字证书中的公钥确实是“服务器”的。检查数字证书后,“客户”会发送一个随机的字符串给“服务器”用私钥去加密,服务器把加密的结果返回给“客户”,“客户”用公钥解密这个返回结果,如果解密结果与之前生成的随机字符串一致,那说明对方确实是私钥的持有者,或者说对方确实是“服务器”。

“客户”->“服务器”:向我证明你就是服务器,这是一个随机字符串 //前面的例子中为了方便解释,用的是“你好”等内容,实际情况下一般是随机生成的一个字符串。 “服务器”->“客户”:{一个随机字符串}[私钥|RSA]

step4: 验证“服务器”的身份后,“客户”生成一个对称加密算法和密钥,用于后面的通信的加密和解密。这个对称加密算法和密钥,“客户”会用公钥加密后发送给“服务器”,别人截获了也没用,因为只有“服务器”手中有可以解密的私钥。这样,后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。

“服务器”->“客户”:{OK,已经收到你发来的对称加密算法和密钥!有什么可以帮到你的?}[密钥|对称加密算法]

“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]

“服务器”->“客户”:{你好,你的余额是100元}[密钥|对称加密算法] ?? //继续其它的通信

以上就是课程内容!


实验(相关文件已传至微信群):


实验1.1(网站的搭建)

环境:ubuntu 14;mysql;php5.5;apache2

1.环境安装

sudo apt-get install apache2
sudo apt-get install mysql-server mysql-common mysql-client//密码记好之后要用,用户名默认root
sudo apt-get install php5-common php5-gd libapache2-mod-auth-mysql php5-mysql apache2-mpm-prefork libapache2-mod-php5 php5 php5-cli

2.建数据库

进数据库:mysql -uroot -p

create database myzoo;
use myzoo; 
create table Person(PersonID int primary key auto_increment, Password varchar(100),Salt varchar(100),Username varchar(100),Token varchar(100),Zoobars int default 10, Profile varchar(5000));
退出数据库:quit


3.把燕姐提供的myzoo文件夹拷贝到var/www(不需要新建,系统里有的)目录下


4.进到myzoo文件夹(myzoo如果进不去就需要修改权限chmod -R 777 myzoo/)


5.修改database.class.php

cd includes/
sudo vim database.class.php
修改用户名为“root” ,密码为自己设定的,数据库名为“myzoo”


6.修改000-default.conf(文件目录:etc/apache2/sites-available/000-default.conf)

sudo vim 000-default.conf
将DocumentRoot /var/www/html中的html替换为myzoo


7.重启apache2

sudo service apache2 restart
8.打开浏览器

输入:localhost(动物园就出现了)




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章