截至到目前已经确认的漏洞一览图：

1、绿盟UTS综合威胁探针管理员任意登录

2、用友GRP-u8 XXE注入

3、天融信TopApp-LB 负载均衡系统sql注入

4、深信服EDR远程命令执行

5、联软科技产品存在任意文件上传

6、联软科技产品存在命令执行漏洞

7、WPS命令执行漏洞

8、齐治堡垒机漏洞

9、phpcms v9前台REC（全版本），这个详情在我的GitHub，二十几天前就搜集到了。

漏洞预警，蓝队撑住，提前预警，做好预防0day冲击准备，不一定全部是真的，有这些产品的多注意，多加一道防护，比如开启basic二次验证等操作缓解预防！

预警事项：山石、绿盟、新华三、华为等多个安全产品存在漏洞

根据互联网情报，多款安全产品疑似存在零日或高危漏洞，涉及山石网科下一代防火墙、绿盟远程安全评估系统， 新华三技术有限公司H3CSecPathF10x 0防火墙、华为多款产品(交换机、入侵防御系统、防火墙等)，政击者可能通过利用以上漏润造成重大安全影响。

预警时间：2020年09月12日

预警等级：八级

预警范围：

1.山石网科下一代防火墙SG-6000

2.绿盟远程安全评估系统

3.新华三技术有限公司H36SecPathF10x 0防火墙

4.华为多款设备存在越界读取漏洞(C NVD-2020-36735) ：

华为无线接入点设备AP2000系列

华为交换机S5700系列

华为DDOS防御系统Seco space Anti DDoS 8000系列

华为下一代入侵防御系统NIP 5300系列、NIP 6600系列、NIP 6800系列

华为入侵防御系统(单板形态) IPS Module V 500系列

H3C、启明星辰、天融信、网御星云、深信服、网神等多个安全产品存在漏洞

预警事项：

根据互联网情报，多款安全产品疑似存在零日或高危漏洞，涉及北京启明星辰信息安全技术有限公司天清Web应用安全网关、天融信NG FW下一代防火墙、H3CACG 1000-M交换机、北京网御星云信息技术有限公司网御防火墙、深信服科技股份有限公司SSL VPN，网神信息技术(北京)股份有限公司网神安全审计系统，攻击者可能通过利用以上漏洞造成重大安全影响。

预警时间：2020年9月12日

预警等级：九级

预警范围：

1.北京启明星辰信息安全技术有限公司天清Web应用安全网关

2.天融信NGE W下一代防火墙

3.北京网御星云信息技术有限公司网御防火墙

4.深信服科技股份有限公司SSL VPN

5.网神信息技术(北京)股份有限公司 网神安全审计系统

6.H3CACG 1000-M交换机

祝大家HW顺利！少丢分！哈哈哈

近期，有匿名黑客开始泄露伊朗间谍组织APT 34（OilRig 或者 HelixKitten） 所使用的黑客工具，甚至还包括团队成员及受害者数据信息等等。虽然目前来看所泄露的工具并没有永恒之蓝如此复杂，但依然引发了大量安全研究者的持续关注。 从3月份开始，有人开始以“Lab Dookhtegan”这个名字在Telegram频道 https://t.me/lab_dookhtegan 中分享这些数据，截止我发这篇文章之时，已经有接近3100+人密切关注该频道发布的内容。

其中有118条 webshell  大多都是 OA系统 或者邮箱，APT 34 组织很会挑对象啊，这些系统都是有很多的有价值的数据。我注意了一下其中包含 China 的 webshell 就有13条，包括 www.cecep.cn(中国节能环保集团公司)、generali-china.cn(中意财产保险有限公司)、exchange.bestv.com.cn(BesTV网站-BesTV百变新视界)、bdo.com.cn(BDO立信)、lswebext.sdec.com.cn(上海柴油机股份有限公司(简称“上柴股份”))、mail.swsc.com.cn(西南证券)、mail.neway.com.cn(苏州纽威阀门股份有限公司)、crccre.cn(中国铁建房地产集团有限公司)，这些都是中国的公司，其中不乏一些大公司。如下图所示，其中大部分的邮箱OA系统应该都是同一套系统,估计APT 34组织有对应的 0day 或者是公司内部安全建设差，总之都是受害者，更应该反思。



更多详细的wenshell相关信息可以去这里看：https://pastebin.com/jVcZc8pR 当然文末也有目前已经放出来的所有的文件打包下载地址。

截止目前，该匿名者已经放出了6款黑客工具：

1.Glimpse（基于PowerShell的的新版木马，Palo Alto Networks命名为BondUpdater）

2.PoisonFrog（旧版BondUpdater）

3.HyperShell（称之为TwoFace的Palo Alto Networks网络外壳）

4.HighShell（另一个Web shell）

5.Fox Panel（钓鱼工具包）

6.Webmask（DNS隧道，DNSpionage背后的主要工具）

研究人员还检查了两个Web shell，发现HyperShell中名为“p”的cookie需要正确的密码才能获得访问权限。此外，Dookhtegan将所有最有意义的密码更改为“Th！sNotForFAN”。安全专家已确认这些泄露的工具和信息确实与APT 34组织有关。 Dookhtegan发布的信息还包括66名APT34组织受害者，主要是中东地区的政府机构和财务 能源公司，这与APT 34组织的先前情况一致。在有关受害者的阿联酋总统事务办公室（mopa.ae）的信息中，它还包括大约900个用户名和密码以及80多个webmail访问凭证。迪拜媒体公司的文件包括250多张优惠券。阿提哈德航空公司的信息包括10,000个用户名和明文密码，并通过Windows密码恢复工具的“高级版”破解获得。其他文件包括服务器信息 数据库转储和Mimikatz后利用工具输出数据。

目前泄露所有内容包下载地址：
https://s3-eu-west-1.amazonaws.com/malware-research.org/blogposts/apt34Leak/apt34leak.7z
解压缩密码：vJrqJeJo2n005FF *

原文地址：https://malware-research.org/apt34-hacking-tools-leak/

centos开启SSH的密钥登录相信大家都会吧,而且很多的一键脚本都会配备,比如wdlinux面板的一件安装包都会配备而且支持自定义修改SSH端口,和一键生成密钥,很方便的,但是我们有时候没有必要安装这些一键脚本(比如内存小,不是用来做web服务的等等原因就不细说了);比如我们只是在梯子服务器上安装呢?这就需要我们自己手动了.博主我呢也经常折腾linux服务器,自己的或朋友的,今天抽时间写这篇文章,把我配置SSH密钥过程中遇到的坑都一一道来,

一来是做个总结,二来是方便后人^^.不要再往坑了跳了!跳了的也能尽快出坑!(此处应有掌声 -_-|)

先来看配置SSH的步骤

大致分为以下下几步：

• 本地使用xshell软件生成公钥(不推荐linux端生成,照顾小白)
• 使用非常著名方便小巧的运维工具--lrzsz(点我传送)--来上传公钥到服务端
• 服务端常规配置（会附上详细的步骤shell操作代码）
• 本文的重点--常见的坑的排除,解决方法（附上几种出错的情况以及解决办法）
  

1.本地使用xshell软件生成公钥:

• 在xshell的工具栏里面找到 工具-新建用户密钥向导 如下图所示: 

• 

• *密钥类型推荐使用RSA,密钥长度为2048的,即软件推荐的默认长度. 
  

• 然后下一步,等待自动生成公钥对,
• 然后下一步,给用户密钥设置一个密码,如下图所示,设置密码,即使别人拿到你得密钥也没法用,双重保险. 

• 然后点击下一步到公钥注册界面,选择公钥格式: SSH2-OpenSSH(因为现在大多数的linux的SSH都支持2.0保护方式,而且更保险.),然后,如下图所示保存为文件,在弹出的窗口,选择一个地方保存公钥 .pub 文件, 默认是id_rsa_2048.pub,方便自己查找的一个地方,比如桌面.

2.SSH登录服务器,把id_rsa_2048.pub上传到服务器上并注册公钥,配置SSH

• 上传可以参考我这篇文章 lrzsz(点我传送) ,如果安装好了lrzsz,只需要一条命即可把pub文件上传到服务器,输入:rz 然后在弹出的窗口选择上传的文件即可,如果出现报错,暂时关闭防火墙即可.
• 其实使用sftp也可以在xshell里直接传文件,但是我不常用没有做,抱歉,但是教程网上有的,搜索一下即可.

3.服务端注册公钥.pub文件到系统,并分配好权限,权限没设置好后面登录会出问题的,这就是其中的一个坑,很多人都被坑过...具体步骤如下代码 :

就是把id_rsa_2048.pub的内容替换到/root/.ssh/下: 
[root@test ~]# ls -a 
.            ..         id_rsa_2048.pub
[root@test ~]# mkdir .ssh
[root@test ~]# chmod 700 .ssh/
[root@test ~]# cd .ssh/
[root@test .ssh]# cat ../id_rsa_2048.pub > ./authorized_keys
[root@test .ssh]# ls
authorized_keys
[root@test .ssh]# chmod 600 authorized_keys
[root@test ~]# diff id_rsa_2048.pub .ssh/authorized_keys 
[root@test ~]#

最后的diff命令来比较两个文件,确保文件内容相同。

4.接下来配置server的ssh服务（/etc/ssh/sshd_config）只允许使用密钥登录不允许口令登录(小提示:sshd重启完先不要关闭当前的ssh链接,以防万一)：

[root@test~]:# vi /etc/ssh/sshd_config
#然后在vi界面用i来insert修改,找个空,回车一下,粘贴下面的代码
PasswordAuthentication no                    # 不允许口令登录
PubkeyAuthentication yes                     # 使用key登录
AuthorizedKeysFile .ssh/authorized_keys      # key的名字
#然后Esc,输入冒号:wq,保存退出

service sshd restart   #重启ssh服务

现在暂时不修改端口,不然修改完端口很多童鞋就直接exit了,就GG了,因为很多人的iptables规则没有设置就退出了,结果就进不去了,要是vps有控制台还好,可以通过控制台的VNC修改配置文件.要是没有就麻烦了.

这时候,xshell新开一个窗口,输入你的服务器IP,端口,默认22,然后回车链接,在弹出的对话框输入用户名,root,然后选择public key,在用户密钥里选择刚刚生成的那个,默认名字是id_rsa_2048,然后在下面输入刚刚设置的密钥密码,登录,看是否正常,如果正常登录,就OK了,然后就可以去修改端口,修改防火墙了:

修改端口,直接,vi /etc/ssh/sshd_config,增加一行,Port  3211 #端口请随意,但要记住.

然后防火墙增加一条规则允许 32211端口链接,命令大概如下,具体的请自行酌情修改:

iptables -A INPUT -p tcp --dport 3211 -j ACCEPT   /*允许包从3211端口进入*/
iptables -A OUTPUT -p tcp --sport 3211 -m state --state ESTABLISHED -j ACCEPT  /*允许从3211端口进入的包返回*/
service iptables save   /*保存配置*/
service iptables restart  /*重启iptables*/

下面说一下常见的坑(错误),如何爬出来:

1. 配置完,使用密钥登录时,提示:所选用户密钥未在远程主机上注册.请再试一次.

这时候,请先检查存放authorized_keys的文件的权限,是否为600或者是644,如果不知道怎么看,那就直接执行下面的命令一次好了:

chmod 600 .ssh/authorized_keys 即可或者 644 也行. #600权限即-rw-------

注:执行这些命令的前提是,默认你是root账户,且在root目录下.如果不是,请自行调整用户和目录.不懂得可以留言/评论/发邮件.

然后再次登录,成功就不说了,没成功请继续往下看:

没成功就请查看登录日志,具体的命令如下(centos为例,其他的linux目录可能不一样,请注意):

cat /var/log/secure

如果出现如图所示的 xxx because account is locked :

这种有可能是用户被锁定了，于是查看状态 准备解锁用户，命令如下：
pam_tally2 --user root  #root为你需要登录的账号
pam_tally2 -r -u root   #root为你需要登录的账号

通过pam_tally2 --user 指令发现没有锁定,都是0，
[root@test~]# pam_tally2 --user root
Login           Failures Latest failure     From
root                0    
[root@test~]# pam_tally2 -r -u root
Login           Failures Latest failure     From
root                0    
那就有可能是sshd没开启PAM 
修改/etc/ssh/sshd_config 配置后 ，再次登录测试，应该能解决问题

       2.如果按照上面这些修改完还是登录不进去,并且查看日志,大概内容如下:

Mar 29 01:36:12 localhost sshd[2645]: Received disconnect from 192.123.123.123: 11: Bye Bye
Mar 29 01:49:48 localhost sshd[2031]: Received signal 15; terminating.
Mar 29 01:49:48 localhost sshd[2704]: Server listening on 0.0.0.0 port 22.
Mar 29 01:49:48 localhost sshd[2704]: Server listening on :: port 22.
Mar 29 01:50:12 localhost sshd[2707]: Received disconnect from 192.123.123.123: 0: 
Mar 29 01:50:43 localhost sshd[2784]: Received disconnect from 192.123.123.123: 0: 
Mar 29 01:52:21 localhost sshd[2812]: Received disconnect from 192.123.123.123: 0: 

出错的是直接就断开了连接,并且没有任何错误提示,请检查服务器的selinux和iptables是否开启,iptables前面讲过,开放想相应端口,

如果还是连接不上,那就检查selinux, 使用下面的代码检查selinux 是否开启 :

查看SELinux状态：
1、/usr/sbin/sestatus -v      ##如果SELinux status参数为enabled即为开启状态
SELinux status:                 enabled
2、getenforce                 ##也可以用这个命令检查
关闭SELinux：
1、临时关闭（不用重启机器）：
setenforce 0                  ##设置SELinux 成为permissive模式
                              ##setenforce 1 设置SELinux 成为enforcing模式
2、修改配置文件需要重启机器：
修改/etc/selinux/config 文件
将SELINUX=enforcing改为SELINUX=disabled
重启机器即可  #reboot

目前就写这么多,欢迎补充,交流!

我们下次再会.

一直在各大常逛的网站看到关于Badusb的文章，顿时觉得很神奇，很高端，于是一直想拥有这么一个邪恶的东西，可是因为2303不是很好找，并且git上的编译写入过程一看就头大，所以一直搁浅了，可是并没放弃，扯远了，扯回来。 

PS:英文好的同学可以直接去Git看官方教程 
PS：发现关于Badusb的详细教程文章国内寥寥无几，大牛们肯定都是在躲着玩..让后来想学的小白怎么办

俄罗斯大神发的帖子，有制作视频，查资料去看吧：https://dmyt.ru/forum/viewtopic.php?f=7&t=383

需要的环境&工具

0.2303芯片的U盘  （废话...）
1.Visual Studio 2012（编译所需工具用，可选安装，我会编译打包好） 
2.Java环境  （执行encoder所需） 
3..NET framework 4.5（系统自带，没有请到微软官网下载） 
4.SDCC  http://sdcc.sourceforge.net   //安装至C:\Program Files\SDCC目录下 
5.Duckencoder（编译攻击代码） 
6.Burner File BN03V104M.BIN  （2303固件）         
7.Psychson  （Badusb写入工具 https://github.com/adamcaudill/Psychson/） 
8.攻击payload  （想要执行的攻击代码） 
9.主控芯片查看工具  （可选，查看U盘主控芯片信息）

1.下载&编译攻击代码 
https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Payloads 
你可以使用HelloWorld测试，也可以用Downer下载exe并运行（第二次刷入比较麻烦，建议第一次就选好想要的payload

2.生成固件&将攻击代码写入固件

3.将生成的固件写入U盘

就不每个都传图了，直接上写入成功的图：

文件打包下载链接:链接:http://pan.baidu.com/s/1jIm22bk 密码:mrxn

疑问讨论：（玩过的大牛，都别躲着玩了，快出来科普问题，或说说猥琐的新姿势..） 

1.看漏洞原理，貌似是因为此芯片可编程为其他设备，如Usb键盘，打印机什么的，然后执行代码，那么U盘被编程为了其他设备，是否可以将恶意 exe写入进去，并在插入的时候执行自己存储的exe，而不是执行vbs下载（因为要考虑到内网或没网，执行一个内置并潜伏的程序应该能pass此场景） 

2.貌似它只是模拟了键盘去执行命令，那么在没有powershell的环境里如何做到隐藏执行？cmd有点显眼，虽然一闪而过 

3.如何即让它可以模拟执行命令又能像正常U盘一样存储东西（比较插上U盘结果没出现盘让人感觉有点不对）听说量产工具可以把U盘量产为不同的用途，不知道是否可以用在此处 

end：不想再折腾了。。第一次刷入helloworld成功后还小激动了会，然后发现第二次刷入新的payload出现了错误，在大牛的帮助下才成功使用短接方法重新刷入payload（在没有工具的情况下，拆开U盘橡胶外壳，不要问我是不是咬开的，我徒手撕的..） 

感谢90某大神的耐心回答，几个小时之前都没听说过U盘还有短接这东西。。（此文也是参考自他） 

下一个可能要感谢“一只猿”了，你们猜为什么 

enjoying..（ps：去目（nv）标（shen）那丢U盘吧）

原文：http://www.jeary.org/?post=51

为了提高网站的安全性，一般会在比较敏感的部分页面采用https传输，比如注册、登录、控制台等。像Gmail、网银等全部采用https传输。

上图是IE和Chrome上对https的不同表现。

国外常见的SSL提供商有：Thawte，Go Daddy，VeriSign，RapidSSL，GeoTrust（QuickSSL），StartSSL，Comodo。

这样以上5项测试就都变为正确的结果了，就像用户在直接访问 Tomcat 一样。

原文地址：http://han.guokai.blog.163.com/blog/static/136718271201211631456811/

关于SSL/TLS介绍见文章 SSL/TLS原理详解。
关于证书授权中心CA以及数字证书等概念，请移步 OpenSSL 与 SSL 数字证书概念贴 。

openssl是一个开源程序的套件、这个套件有三个部分组成：一是libcryto，这是一个具有通用功能的加密库，里面实现了众多的加密库；二是libssl，这个是实现ssl机制的，它是用于实现TLS/SSL的功能；三是openssl，是个多功能命令行工具，它可以实现加密解密，甚至还可以当CA来用，可以让你创建证书、吊销证书。

默认情况ubuntu和CentOS上都已安装好openssl。CentOS 6.x 上有关ssl证书的目录结构：

/etc/pki/CA/
            newcerts    存放CA签署（颁发）过的数字证书（证书备份目录）
            private     用于存放CA的私钥
            crl         吊销的证书
/etc/pki/tls/
             cert.pem    软链接到certs/ca-bundle.crt
             certs/      该服务器上的证书存放目录，可以房子自己的证书和内置证书
                   ca-bundle.crt    内置信任的证书
             private    证书密钥存放目录
             openssl.cnf    openssl的CA主配置文件

1. 颁发证书

1.1 修改CA的一些配置文件

CA要给别人颁发证书，首先自己得有一个作为根证书，我们得在一切工作之前修改好CA的配置文件、序列号、索引等等。

vi /etc/pki/tls/openssl.cnf：

...
[ CA_default ]
dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.
certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem # The private key
RANDFILE        = $dir/private/.rand    # private random number file
...
default_days    = 3650                  # how long to certify for
...
# For the CA policy
[ policy_match ]
countryName             = match
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
...
[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = CN
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = GD
...
[ req_distinguished_name ] 部分主要是颁证时一些默认的值，可以不动

一定要注意[ policy_match ]中的设定的匹配规则，是有可能因为证书使用的工具不一样，导致即使设置了csr中看起来有相同的countryName,stateOrProvinceName等，但在最终生成证书时依然报错：

Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
The stateOrProvinceName field needed to be the same in the
CA certificate (GuangDong) and the request (GuangDong)

touch index.txt serial：

在CA目录下创建两个初始文件：

# touch index.txt serial
# echo 01 > serial

1.2 生成根密钥

# cd /etc/pki/CA/
# openssl genrsa -out private/cakey.pem 2048

为了安全起见，修改cakey.pem私钥文件权限为600或400，也可以使用子shell生成( umask 077; openssl genrsa -out private/cakey.pem 2048 )，下面不再重复。

1.3 生成根证书

使用req命令生成自签证书：

# openssl req -new -x509 -key private/cakey.pem -out cacert.pem

会提示输入一些内容，因为是私有的，所以可以随便输入（之前修改的openssl.cnf会在这里呈现），最好记住能与后面保持一致。上面的自签证书cacert.pem应该生成在/etc/pki/CA下。

1.4 为我们的nginx web服务器生成ssl密钥

以上都是在CA服务器上做的操作，而且只需进行一次，现在转到nginx服务器上执行：

# cd /etc/nginx/ssl
# openssl genrsa -out nginx.key 2048

这里测试的时候CA中心与要申请证书的服务器是同一个。

1.5 为nginx生成证书签署请求

# openssl req -new -key nginx.key -out nginx.csr
...
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:GD
Locality Name (eg, city) []:SZ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:COMPANY
Organizational Unit Name (eg, section) []:IT_SECTION
Common Name (e.g. server FQDN or YOUR name) []:your.domain.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
...

同样会提示输入一些内容，其它随便，除了Commone Name一定要是你要授予证书的服务器域名或主机名，challenge password不填。

1.6 私有CA根据请求来签署证书

接下来要把上一步生成的证书请求csr文件，发到CA服务器上，在CA上执行：

# openssl ca -in nginx.csr -out nginx.crt
另外在极少数情况下，上面的命令生成的证书不能识别，试试下面的命令：
# openssl x509 -req -in server.csr -CA /etc/pki/CA/cacert.pem -CAkey /etc/pki/CA/private/cakey.pem -CAcreateserial -out server.crt

上面签发过程其实默认使用了-cert cacert.pem -keyfile cakey.pem，这两个文件就是前两步生成的位于/etc/pki/CA下的根密钥和根证书。将生成的crt证书发回nginx服务器使用。

到此我们已经拥有了建立ssl安全连接所需要的所有文件，并且服务器的crt和key都位于配置的目录下，剩下的是如何使用证书的问题。

2. 使用ssl证书

2.1 一般浏览器

浏览器作为客户端去访问https加密的服务器，一般不用去手动做其他设置，如https://www.google.com.hk，这是因为Chrome、FireFox、Safari、IE等浏览器已经内置了大部分常用的CA的根证书，但自建CA的根证书就不再浏览器的信任列表中，访问时会提示如下：
IE浏览器

谷歌浏览器

安装网站证书后（同时也有信任的根证书），地址栏一般会显示绿色小锁

证书信息

导入证书到浏览器的方法：http://cnzhx.net/blog/self-signed-certificate-as-trusted-root-ca-in-windows/

2.2 为linux系统添加根证书

这一步不是必须的，一般出现在开发测试环境中，而且具体的应用程序应该提供添加证书的方法。

curl工具可以在linux上模拟发送请求，但当它去访问https加密网站时就会提示如下信息：

# curl https://sean:[email protected]:8000/
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

# cp /etc/pki/tls/certs/ca-bundle.crt{,.bak}    备份以防出错
# cat /etc/pki/CA/cacert.pem >> /etc/pki/tls/certs/ca-bundle.crt
# curl https://sean:[email protected]:8000
"docker-registry server (dev) (v0.8.1)"

2.3 nginx

在nginx配置文件（可能是/etc/nginx/sites-available/default）的server指令下添加：

ssl on;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;

同时注意 server_name 与证书申请时的 Common Name 要相同，打开443端口。当然关于web服务器加密还有其他配置内容，如只对部分URL加密，对URL重定向实现强制https访问，请参考其他资料。

3 关于证书申请

注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在web server上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做CA。从ca的角度讲，你需要CA的私钥和公钥。从想要证书的服务器角度将，需要把服务器的证书请求交给CA。

如果你要自己做CA，别忘了客户端需要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。而商业CA的一般不用，因为它们已经内置在你的浏览器中了。

参考

• CentOS6.5下openssl加密解密及CA自签颁发证书详解
• 基于 OpenSSL 的 CA 建立及证书签发
• openssl建立证书，非常详细配置ssl+apache
• The Secure Sockets Layer and Transport Layer Security

SSL/TLS 介绍见文章 SSL/TLS原理详解。
如果你想快速自建CA然后签发数字证书，请移步 基于OpenSSL自建CA和颁发SSL证书 。

首先简单区分一下HTTPS、SSL、OpenSSL三者的关系：

SSL是在客户端和服务器之间建立一条SSL安全通道的安全协议，而OpenSSL是TLS/SSL协议的开源实现，提供开发库和命令行程序。常说的HTTPS是HTTP的加密版，底层使用的加密协议是SSL。

1. PKI、CA与证书

PKI 就是 Public Key Infrastructure 的缩写，翻译过来就是公开密钥基础设施。它是利用公开密钥技术所构建的，解决网络安全问题的，普遍适用的一种基础设施;是一种遵循既定标准的密钥管理平台,它能够为所有网络应用提供加密和数字签名等密码服务及所必需的密钥和证书管理体系。

PKI既不是一个协议，也不是一个软件，它是一个标准，在这个标准之下发展出的为了实现安全基础服务目的的技术统称为PKI。可以说CA(认证中心)是PKI的核心，而数字证书是PKI的最基本元素，还有如apache等服务器、浏览器等客户端、银行等应用，都是pki的组件。这篇文章可以帮助理解：PKI/CA 技术的介绍 。

1.1 CA

为保证用户之间在网上传递信息的安全性、真实性、可靠性、完整性和不可抵赖性

CA 机构，又称为证书认证中心 (Certificate Authority) 中心，是一个负责发放和管理数字证书的第三方权威机构，它负责管理PKI结构下的所有用户(包括各种应用程序)的证书，把用户的公钥和用户的其他信息捆绑在一起，在网上验证用户的身份。CA机构的数字签名使得攻击者不能伪造和篡改证书。

认证中心主要有以下5个功能：

1. 证书的颁发：接收、验证用户(包括下级认证中心和最终用户)的数字证书的申请。可以受理或拒绝
2. 证书的更新：认证中心可以定期更新所有用户的证书，或者根据用户的请求来更新用户的证书
3. 证书的查询：查询当前用户证书申请处理过程；查询用户证书的颁发信息，这类查询由目录服务器ldap来完成
4. 证书的作废：由于用户私钥泄密等原因，需要向认证中心提出证书作废的请求；证书已经过了有效期，认证中心自动将该证书作废。认证中心通过维护证书作废列表 (Certificate Revocation List,CRL) 来完成上述功能。
5. 证书的归档：证书具有一定的有效期，证书过了有效期之后就将作废，但是我们不能将作废的证书简单地丢弃，因为有时我们可能需要验证以前的某个交易过程中产生的数字签名，这时我们就需要查询作废的证书。

1.2 Certificate

1.2.1 X.509标准

“SSL证书”这个词是一个相对较大的概念，整个PKI体系中有很多SSL证书格式标准。PKI的标准规定了PKI的设计、实施和运营，规定了PKI各种角色的”游戏规则”，提供数据语法和语义的共同约定。x.509是PKI中最重要的标准，它定义了公钥证书的基本结构，可以说PKI是在X.509标准基础上发展起来的：

• SSL公钥证书
• 证书废除列表CRL(Certificate revocation lists 证书黑名单)

参考 http://en.wikipedia.org/wiki/X.509 。

另外一个常用的标准是PKCS#12，通常采用pfx,p12作为文件扩展名，openssl和java的keytool工具都可以用作生产此类格式的证书。

1.2.2 ssl公钥证书格式

1. 证书版本号(Version)
版本号指明X.509证书的格式版本，现在的值可以为:
    1) 0: v1
    2) 1: v2
    3) 2: v3
也为将来的版本进行了预定义
2. 证书序列号(Serial Number)
序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，
这也是序列号唯一的原因。
3. 签名算法标识符(Signature Algorithm)
签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:
    1) 公开密钥算法
    2) hash算法
example: sha256WithRSAEncryption
须向国际知名标准组织(如ISO)注册
4. 签发机构名(Issuer)
此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址
5. 有效期(Validity)
指定证书的有效期，包括:
    1) 证书开始生效的日期时间
    2) 证书失效的日期和时间
每次使用证书时，需要检查证书是否在有效期内。
6. 证书用户名(Subject)
指定证书持有者的X.500唯一名字。包括:
    1) 国家(C)
    2) 省市(ST)
    3) 地区(L)
    4) 组织机构(O)
    5) 单位部门(OU)
    6) 通用名(CN)
    7) 邮箱地址
7. 证书持有者公开密钥信息(Subject Public Key Info)
证书持有者公开密钥信息域包含两个重要信息:
    1) 证书持有者的公开密钥的值
    2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。
8. 扩展项(extension)
X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指
由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来
注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。
9. 签发者唯一标识符(Issuer Unique Identifier)
签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串
来唯一标识签发者的X.500名字。可选。
10. 证书持有者唯一标识符(Subject Unique Identifier)
持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，
用一比特字符串来唯一标识证书持有者的X.500名字。可选。
11. 签名算法(Signature Algorithm)
证书签发机构对证书上述内容的签名算法
example: sha256WithRSAEncryption
12. 签名值(Issuer's Signature)
证书签发机构对证书上述内容的签名值

example:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=GuangDong, L=ShenZhen, O=COMPANY Technologies Co., Ltd, OU=IT_SECTION, CN=registry.example.com.net/[email protected]
        Validity
            Not Before: Feb 11 06:04:56 2015 GMT
            Not After : Feb  8 06:04:56 2025 GMT
        Subject: C=CN, ST=GuangDong, L=ShenZhen, O=TP-Link Co.,Ltd., OU=Network Management, CN=172.31.1.210
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a4:b0:dd:eb:c1:cf:5d:47:61:a6:ea:ef:8b:aa:
                    4b:f0:b4:2c:d8:96:c7:7c:ac:fa:c7:35:88:53:d0:
                    ...
                    8a:76:dc:8f:8c:44:c8:0b:3c:36:88:5f:01:f0:44:
                    4e:81:e6:7a:2b:ff:ba:da:33:a5:27:11:c6:f0:08:
                    6e:f3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                07:C6:87:B7:C1:1E:28:E8:96:3F:EB:40:1E:82:41:45:CA:81:B6:3D
            X509v3 Authority Key Identifier: 
                keyid:A4:C2:14:6A:39:D1:95:1E:BD:DF:3B:92:4A:5C:12:42:1B:BC:53:B8
    Signature Algorithm: sha256WithRSAEncryption
         0c:c6:81:70:cd:0a:2d:94:4f:cb:a4:1d:ef:9e:8e:e4:73:ae:
         50:62:a8:9c:64:ef:56:0f:41:fe:6b:b4:d3:07:37:39:2c:ed:
         ...
         6f:62:61:b8:03:d7:97:31:ab:05:44:20:07:65:8b:ad:e2:cc:
         ad:65:73:f6:82:0f:9e:65:d0:ae:b7:1e:fd:9f:c1:d7:41:6c:
         0f:06:95:ee
-----BEGIN CERTIFICATE-----
MIIEMDCCAxigAwIBAgIBCTANBgkqhkiG9w0BAQsFADCBtTELMAkGA1UEBhMCQ04x
EjAQBgNVBAgMCUd1YW5nRG9uZzERMA8GA1UEBwwIU2hlblpoZW4xJjAkBgNVBAoM
...
ujwwRar6pPzusO95WuS93HsNmL2ZFZ63DS4LcW9iYbgD15cxqwVEIAdli63izK1l
c/aCD55l0K63Hv2fwddBbA8Gle4=
-----END CERTIFICATE-----

2. 附：数据加密的基础知识

对称密钥加密

对称密钥加密（一个密钥），也叫做共享密钥加密或机密密钥加密，使用发件人和收件人共同拥有的单个密钥。这种密钥既用于加密，也用于解密，叫做机密密钥。对称密钥加密是加密大量数据的一种行之有效的方法。

对称密钥加密有许多种算法如DES,RC4,IDEA等，但所有这些算法都有一个共同的目的：以可还原的方式将明文 （未加密的数据转换为暗文。暗文使用加密密钥编码，对于没有解密密钥的任何人来说它都是没有意义的。由于对称密钥加密在加密和解密时使用相同的密钥，所以这种加密过程的安全性取决于是否有未经授权的人获得了对称密钥。

衡量对称算法优劣的主要尺度是其密钥的长度。密钥越长，在找到解密数据所需的正确密钥之前必须测试的密钥数量就越多。需要测试的密钥越多，破解这种算法就越困难。

公钥加密

公钥加密使用两个密钥:一个公钥和一个私钥，这两个密钥在数学上是相关的。为了与对称密钥加密相对照，公钥加密有时也叫做不对称密钥加密。在公钥加密中，公钥可在通信双方之间公开传递，或在公用储备库中发布，但相关的私钥是保密的。只有使用私钥才能解密用公钥加密的数据。使用私钥加密的数据只能用公钥解密。下图中，发件人拥有收件人的公钥，并用它加密了一封邮件，但只有收件人掌握解密该邮件的有关私钥。

公钥算法的主要局限在于，这种加密形式的速度相对较低。实际上，通常仅在关键时刻才使用公钥算法，如在实体之间交换对称密钥时，或者在签署一封邮件的散列时（散列是通过应用一种单向数学函数获得的一个定长结果，对于数据而言，叫做散列算法）。将公钥加密与其它加密形式（如对称密钥加密）结合使用，可以优化性能，如数字签名和密钥交换。

常用公钥算法：

• RSA：适用于数字签名和密钥交换。 是目前应用最广泛的公钥加密算法，特别适用于通过 Internet 传送的数据，RSA算法以它的三位发明者的名字命名。
• DSA：仅适用于数字签名。 数字签名算法 (Digital Signature Algorithm, DSA) 由美国国家安全署 (United States National Security Agency, NSA) 发明，已作为数字签名的标准。DSA 算法的安全性取决于自计算离散算法的困难。这种算法，不适用于数据加密。
• Diffie-Hellman：仅适用于密钥交换。 Diffie-Hellman 是发明的第一个公钥算法，以其发明者 Whitfield Diffie 和 Martin Hellman 的名字命名。Diffie-Hellman 算法的安全性取决于在一个有限字段中计算离散算法的困难。

单向散列算法

散列，也称为散列值或消息摘要 ，是一种与基于密钥（对称密钥或公钥）的加密不同的数据转换类型。散列就是通过把一个叫做散列算法的单向数学函数应用于数据，将任意长度的一块数据转换为一个定长的、不可逆转的数字，其长度通常在128～256位之间。所产生的散列值的长度应足够长，因此使找到两块具有相同散列值的数据的机会很少。如发件人生成邮件的散列值并加密它，然后将它与邮件本身一起发送。而收件人同时解密邮件和散列值，并由接收到的邮件产生另外一个散列值，然后将两个散列值进行比较。如果两者相同，邮件极有可能在传输期间没有发生任何改变。

下面是几个常用的散列函数：

• MD5：是RSA数据安全公司开发的一种单向散列算法，MD5被广泛使用，可以用来把不同长度的数据块进行暗码运算成一个128位的数值。
• SHA-1：与 DSA 公钥算法相似，安全散列算法1（SHA-1）也是由 NSA 设计的，并由 NIST 将其收录到 FIPS 中，作为散列数据的标准。它可产生一个 160 位的散列值。SHA-1 是流行的用于创建数字签名的单向散列算法。
• MAC（Message Authentication Code）：消息认证代码，是一种使用密钥的单向函数，可以用它们在系统上或用户之间认证文件或消息，常见的是HMAC（用于消息认证的密钥散列算法）。
• CRC（Cyclic Redundancy Check）：循环冗余校验码，CRC校验由于实现简单，检错能力强，被广泛使用在各种数据校验应用中。占用系统资源少，用软硬件均能实现，是进行数据传输差错检测地一种很好的手段（CRC 并不是严格意义上的散列算法，但它的作用与散列算法大致相同，所以归于此类）。

数字签名：结合使用公钥与散列算法

数字签名是邮件、文件或其它数字编码信息的发件人将他们的身份与信息绑定在一起（即为信息提供签名）的方法。对信息进行数字签名的过程，需要将信息与由发件人掌握的秘密信息一起转换（使用私钥）为叫做签名的标记。数字签名用于公钥环境（任何人都可以拥有）中，它通过验证发件人确实是他或她所声明的那个人，并确认收到的邮件与发送的邮件完全相同。

散列算法处理数据的速度比公钥算法快得多。散列数据还缩短了要签名的数据的长度，因而加快了签名过程。

密钥交换：结合使用对称密钥与公钥

对称密钥算法非常适合于快速并安全地加密数据。但其缺点是，发件人和收件人必须在交换数据之前先交换机密密钥。结合使用加密数据的对称密钥算法与交换机密密钥的公钥算法可产生一种既快速又灵活的解决方案。

参考

• openSSL命令、PKI、CA、SSL证书原理
• X.509 wikipeida
• PKI 基础知识
• 数字证书及CA的扫盲介绍

原文地址：http://seanlook.com/2015/01/15/openssl-certificate-encryption/

本文大部分整理自网络，相关文章请见文后参考。

关于证书授权中心CA以及数字证书等概念，请移步 OpenSSL 与 SSL 数字证书概念贴 ，如果你想快速自建CA然后签发数字证书，请移步 基于OpenSSL自建CA和颁发SSL证书 。

SSL/TLS作为一种互联网安全加密技术，原理较为复杂，枯燥而无味，我也是试图理解之后重新整理，尽量做到层次清晰。正文开始。

1. SSL/TLS概览

1.1 整体结构

SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下:

• SSL：（Secure Socket Layer，安全套接字层），为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
  SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

• TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。
  TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL/TLS协议提供的服务主要有：

1. 认证用户和服务器，确保数据发送到正确的客户机和服务器；
2. 加密数据以防止数据中途被窃取；
3. 维护数据的完整性，确保数据在传输过程中不被改变。

1.2 TLS与SSL的差异

1. 版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
2. 报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
3. 伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
4. 报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
5. 密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。
6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
7. 加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。
8. 填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。

TLS的主要增强内容

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

1. 更安全的MAC算法
2. 更严密的警报
3. “灰色区域”规范的更明确的定义

TLS对于安全性的改进

1. 对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
2. 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
3. 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
4. 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
5. 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

2. 密钥协商过程——TLS握手

SSL协议分为两部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。

由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。

2.1 客户端发出请求（ClientHello）

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

综上，在这一步，客户端主要向服务器提供以下信息：

1. 支持的协议版本，比如TLS 1.0版
2. 一个客户端生成的随机数，稍后用于生成"对话密钥"
3. 支持的加密方法，比如RSA公钥加密
4. 支持的压缩方法

2.2 服务器回应（SeverHello)

上图中，从Server Hello到Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。

服务端在接收到客户端的Client Hello之后，服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如，客户端收到了一个来自于称自己是www.alipay.com的数据，但是如何证明对方是合法的alipay支付宝呢？这就是证书的作用，支付宝的证书可以证明它是alipay，而不是财付通。证书是需要申请，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。另外，证书还有个有效期。

在服务端向客户端发送的证书中没有提供足够的信息（证书公钥）的时候，还可以向客户端发送一个 Server Key Exchange，

此外，对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

跟客户端一样，服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。

最后服务端会发送一个Server Hello Done消息给客户端，表示Server Hello消息结束了。

综上，在这一步，服务器的回应包含以下内容：

1. 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
2. 一个服务器生成的随机数，稍后用于生成"对话密钥"
3. 确认使用的加密方法，比如RSA公钥加密
4. 服务器证书

2.3 客户端回应（Certificate Verify）

Client Key Exchange

如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。

Certificate Verify
接着，客户端需要对服务端的证书进行检查，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥。然后，向服务器发送下面三项信息：

1. 一个随机数。该随机数用服务器公钥加密，防止被窃听
2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验

上面第一项的随机数，是整个握手阶段出现的第三个随机数，它是客户端使用一些加密算法(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个Key叫 PreMaster Secret，很多材料上也被称作 PreMaster Key。

ChangeCipherSpec
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

在ChangecipherSpec传输完毕之后，客户端会使用之前协商好的加密套件和Session Secret加密一段 Finish 的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

2.4 服务器的最后回应（Server Finish）

服务端在接收到客户端传过来的 PreMaster 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成 Session Secret，一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。

2.5 几个secret

Secret Keys
上面的分析和讲解主要是为了突出握手的过程，所以PreMaster secret，Master secret，session secret都是一代而过，但是对于Https，SSL/TLS深入的理解和掌握，这些Secret Keys是非常重要的部分。所以，准备把这些Secret Keys抽出来单独分析和讲解。

我们先来看看这些Secret Keys的生成过程以及作用流程图：

PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。在客户端使用服务端的公钥对PreMaster Secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

关于PreMaster Secret(Key)的计算请参考 Https SSL/TLS PreMaster/Master Secret(Key)计算。

Master secret
上面已经提到，由于服务端和客户端都有一份相同的PreMaster secret和随机数，这个随机数将作为后面产生Master secret的种子，结合PreMaster secret，客户端和服务端将计算出同样的Master secret。

Master secret是有系列的hash值组成的，它将作为数据加解密相关的secret的 Key Material 的一部分。Key Material最终解析出来的数据如下：

其中，write MAC key，就是session secret或者说是session key。Client write MAC key是客户端发数据的session secret，Server write MAC secret是服务端发送数据的session key。MAC(Message Authentication Code)，是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。

关于Session Secret(Key)的计算请参考 Https SSL/TLS Session Secret(Key)计算。

2.6 应用数据传输

在所有的握手阶段都完成之后，就可以开始传送应用数据了。应用数据在传输之前，首先要附加上MAC secret，然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后，使用Client write encryption key进行解密，客户端收到服务端的数据之后使用Server write encryption key进行解密，然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。

2.7 总结

SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个ClientHello来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个ServerHello，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。

3. 附：密钥协商的形象化比喻

如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。

B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。

A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量（IV）和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]

B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

4. SSL安全性

SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论， 目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以通过man in the middle攻击来截获https的消息。

从上面的原理可知，SSL的结构是严谨的，问题一般出现在实际不严谨的应用中。常见的攻击就是middle in the middle攻击，它是指在A和B通信的同时，有第三方C处于信道的中间，可以完全听到A与B通信的消息，并可拦截，替换和添加这些消息。

1. SSL可以允许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便无法验证B的公钥和身份的真实性，从而C可以轻易的冒充，用自己的密钥与双方通信，从而窃听到别人谈话的内容。
   而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
2. 有了证书以后，如果C用自己的证书替换掉原有的证书之后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
3. 由于美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，如果只采用浏览器自带的加密功能的话，理论上存在被破解可能。

5. 代理

下面探讨一下SSL的代理是怎样工作的
当在浏览器里设置了https的代理，而且里输入了https://www.example.com之后，浏览器会与proxy建立tcp链接，然后向其发出这么一段消息：

 CONNECT server.example.com:443 HTTP/1.1
   Host: server.example.com:443 

然后proxy会向webserver端建立tcp连接,之后，这个代理便完全成了个内容转发装置。浏览器与web server会建立一个安全通道，因此这个安全通道是端到端的，尽管所有的信息流过了proxy,但其内容proxy是无法解密和改动的（当然要由证书的支持，否则这个地方便是个man in the middle攻击的好场所，见上面的安全部分）。

CA证书以及如何使用OpenSSL自签署，见文章OpenSSL自签署证书 。

6. 参考

• Https(SSL/TLS)原理详解
• SSL与TLS的区别以及介绍
• SSL/TLS协议运行机制的概述
• SSL/TLS/WTLS原理
• Transport Layer Security (TLS)
• 传输层安全协议
• Survival guides - TLS/SSL and SSL (X.509) Certificates

原文链接地址：http://seanlook.com/2015/01/07/tls-ssl-understand/ (国外，需要梯子请在本博客搜索，关键字：查资料)

今天我的一位仁兄被人误导说HTTPS慢，就这个问题我们来浅谈下HTTPS的速度和安全。首先HTTPS是一个优良而且很棒的协议，他为服务器和客户端之间的数据传输提供了强有力的保障。浅谈HTTPS的速度和安全事实证明HTTPS速度是快的。

Mrxn通过实验测试结果证明，HTTPS确实需要CPU来中断SSL连接，这需要的处理能力对于现代计算机而言是小菜一碟了，你会遇到SSL性能瓶颈的可能性完全为0，首屏加载时间与HTTP协议的时间几乎一致。慢，只会在你网络出现问题的时候发生，和SSL/HTTPS毫无干系，或者极有是你的应用程序性能上遇到瓶颈。
HTTPS是一个重要的连接保障
虽然HTTPS并不放之四海而皆准的web安全方案，但是没有它你就不能以策万全。所有的web 安全都倚赖你拥有了HTTPS。如果你没有它，不管对密码做了多强的哈希加密，或者做了多少数据加密，攻击者都可以简单的模拟一个客户端的网络连接，读取它们的安全凭证，极具威胁。此外，证书签名很显然不是一个完美的实践，但每一种浏览器厂商针对认证机构都有相当严格和严谨的规则。要成为一个受到信任的认证机构是非常难的，而且要保持自己良好的信誉也同样是困难的。
HTTPS流量拦截可以避免
本质上讲，可以使自己的客户只去信任真正可用的 SSL 证书，有效的阻挡所有类型的SSL MITM攻击，如果你是要把 SSL 服务部署到一个不受信任的位置，你最应该考虑使用SSL证书。
HTTPS拥有免费的证书服务
国内和国外都提供了免费的基础等级SSL证书，普及了SSL的支持。 一旦让加密的方案上线，你就能够对你的网站和服务进行100%的加密，完全没有任何花费。
HTTP 在私有网络上并不安全
如果一个攻击者获得了对你的任何内部服务的访问权限，所有的HTTP流量都将会被拦截和解读，这就是为什么HTTPS不管是在公共网络还是私有网络都极其重要的原因。如果是把服务部署在AWS上面，就不要想让你的网络流量是私有的了，因为AWS网络就是公共的，这意味着其它的AWS用户都潜在的能够嗅探到你的网络流量。
2015年百度启用HTTPS搜索
在2015年5月，百度也启用了HTTPS安全搜索，并且支持HTTPS站点的积极优先收录，更可以证明，互联网巨头也开始注重网络传输安全了。
总结
如果你正在做网页服务，毫无疑问，你应该使用 HTTPS。它很容易且能获得用户信任，没有理由不用它。作为ICP，作为程序员我们必须要承担起保护用户的重任。
PS：没有经过事实验证的任何说法，不值得我们信任！

最近在研究ssl，所以就给自己得博客使用了ssl，拿自己的博客实战研究ssl，哈哈，废话不说，如果你也想体验一下ssl，那就开始吧：

科普一下（ssl有啥好处呢）：参考-浅谈HTTPS链接的重要性和安全性 这篇文章。

ssl传送大概示意图：

emlog配置ssl很简单，只需要三步：

第一步：申请ssl证书，学习研究推荐使用免费的ssl证书（如果你是土豪，请无视-_-|），申请教程不写了，没时间，google搜索一大把。

第一个：https://www.startssl.com/ 第二个：https://www.wosign.com/  第一个是英语的，如果看不懂就用第二个国内的，但是国内的只支持sha1算法，国外的可以选择sha2-256位RSA公钥，和4096位的服务器crt身份密钥，更高的加密算法。效果请查看我的网站。

申请成功解压之后，文件目录结构如下图所示：

因为这里我们是用NGINX WEB环境的，所以我们需要解压FOR NGINX.ZIP文件包，然后看到一个CRT一个KEY文件。

openssl rsa -in ssl.key -out /root/ssl.key
chmod 600 /root/ssl.key

登录SSH，执行上述两行脚本，解密私钥和授权。

我们需要在已有的LNMP添加了站点，然后在站点对应的CONF文件设置。

在"/usr/local/nginx/conf/vhost/"目录文件中，找到对应站点的conf文件，然后修改设置如下

server
{
 listen 80;
 listen 443 ssl;
#listen [::]:80;
ssl on;
        ssl_certificate /root/ssl.crt;
        ssl_certificate_key /root/ssl.key;
server_name mrxn.net mrxn.net;

/root/ssl.crt 是我自己的设置，对应路径我们要与之前上传的CRT和KEY文件路径对应以及文件名不要搞错。

最后，我们重启LNMP，可以看到SSL证书生效，且HTTPS可以访问站点。

这是在网站所有资源都在本域名下，而且是https 加密安全访问的情况下。一般你一操作完都不是这样的，而是这样的：

小锁头上面有一个感叹号标志的，如何解决呢：

首先是在后台设置域名地址为：https://mrxn.net 然后，修改 /include/lib/function.base.php ，把头像获取的链接修改成https://开头的：$avatar = "https://cn.gravatar.com/avatar/$hash?s=$s&d=$d&r=$g"; 再回来  数据--更新缓存 之后，打开首页 Ctrl + F5 基本上就是绿色的小箭头了。

如果还没有呢，那多半就是你文章的图片地址是 https://mrxn.net 这样开头的，所以，直接更新数据库的blog表的content和excerpt字段即可：

update emlog_blog set content=replace(content,'https://mrxn.net','https://mrxn.net');

update emlog_blog set excerpt=replace(excerpt,'https://mrxn.net','https://mrxn.net'); 

这样更新完数据库之后，你的网站就基本上全部替换完了非加密连接了（内容页和摘要都更新了，其他的地方貌似没有了，自己写的不算）。
如果我们需要强制使用HTTPS网址访问，那我们就需要取掉 listen 80;脚本。或者是在 listen 80;前面加上# 修改成：#listen 80;

最终修改配置大概如下：

server
    {
        #listen 80;
        listen 443 ssl;
        #listen [::]:80;
        ssl on;
        ssl_certificate 存放ssl证书文件路径.crt;
        ssl_certificate_key 存放ssl证书文件路径.key;
        server_name mrxn.net mrxn.net;
        index index.html index.htm index.php default.html default.htm default.php;
        root  网站存放文件路径;
        keepalive_timeout   60;
       .......此处省略.......
    }
server {
listen 80;
server_name mrxn.net mrxn.net;
return 301 https://mrxn.net$request_uri;
}

注意将域名修改成你自己的域名。至此，基本上就完成了ssl证书的安装，开启https访问了。

相关文章：

一段代码让nginx实现网站资源防盗链

nginx配置location总结及rewrite规则写法

nginx配置ssl加密（单双向认证、部分https）

NginxRewrite规则判断普通用户与搜索引擎爬虫（UA）实现https跳转

SSL/TLS原理详解

OpenSSL 与 SSL 数字证书概念贴

基于OpenSSL自建CA和颁发SSL证书

最后呢，希望有高手带我学习https方面的东西呀，这篇文章呢，也希望对想要使用ssl的童鞋一点帮助，如果哪位看官有更好的方法或者是建议，欢迎留言/评论 不吝赐教啊，我洗耳恭听，多帮忙吧 谢谢。