Ⅰ 常见密码技术简介
##
密码技术在网络传输安全上的应用
随着互联网电子商务和网络支付的飞速发展，互联网安全已经是当前最重要的因素之一。作为一名合格的软件开发工程师，有必要了解整个互联网是如何来保证数据的安全传输的，本篇文章对网络传输安全体系以及涉及到的算法知识做了一个简要的介绍，希望大家能够有一个初步的了解。
###密码技术定义
简单的理解，密码技术就是编制密码和破译密码的一门技术，也即是我们常说的加密和解密。常见的结构如图：
其中涉及到的专业术语：
1.秘钥：分为加密秘钥和解密秘钥，两者相同的加密算法称为对称加密，不同的称为非对称加密；
2.明文：未加密过的原文信息，不可以被泄露；
3.密文：经过加密处理后的信息，无法从中获取有效的明文信息；
4.加密：明文转成密文的过程，密文的长度根据不同的加密算法也会有不同的增量；
5.解密：密文转成明文的过程；
6.加密/解密算法：密码系统使用的加密方法和解密方法；
7.攻击：通过截获数据流、钓鱼、木马、穷举等方式最终获取秘钥和明文的手段。
###密码技术和我们的工作生活息息相关
在我们的日常生活和工作中，密码技术的应用随处可见，尤其是在互联网系统上。下面列举几张比较有代表性的图片，所涉及到的知识点后面都会一一讲解到。
1.12306旧版网站每次访问时，浏览器一般会提示一个警告，是什么原因导致的？ 这样有什么风险呢？
2.360浏览器浏览HTTPS网站时，点开地址栏的小锁图标会显示加密的详细信息，比如网络的话会显示```AES_128_GCM、ECDHE_RSA```，这些是什么意思？
3.在Mac系统的钥匙串里有很多的系统根证书，展开后有非常多的信息，这些是做什么用的？
4.去银行开通网上支付都会附赠一个U盾，那U盾有什么用呢？
##如何确保网络数据的传输安全
接下来我们从实际场景出发，以最常见的客户端Client和服务端Server传输文件为例来一步步了解整个安全体系。
####1. 保密性
首先客户端要把文件送到服务端，不能以明文形式发送，否则被黑客截获了数据流很容易就获取到了整个文件。也就是文件必须要确保保密性，这就需要用到对称加密算法。
** 对称加密： **加密和解密所使用的秘钥相同称为对称加密。其特点是速度快、效率高，适用于对较大量的数据进行加密。常见的对称加密算法有DES、3DES、AES、TDEA、RC5等，让我们了解下最常见的3DES和AES算法：
** DES(Data Encryption Standard)： **1972年由美国IBM研制，数学原理是将明文以8字节分组（不足8位可以有不同模式的填充补位），通过数学置换和逆置换得到加密结果，密文和明文长度基本相同。秘钥长度为8个字节，后有了更安全的一个变形，使用3条秘钥进行三次加密，也就是3DES加密。
**3DES：**可以理解为对明文进行了三次DES加密，增强了安全程度。
** AES(Advanced Encryption Standard)： **2001年由美国发布，2002年成为有效标准，2006年成为最流行的对称加密算法之一。由于安全程度更高，正在逐步替代3DES算法。其明文分组长度为16字节，秘钥长度可以为16、24、32(128、192、256位)字节，根据秘钥长度，算法被称为AES-128、AES-192和AES-256。
对称加密算法的入参基本类似，都是明文、秘钥和模式三个参数。可以通过网站进行模拟测试：[http://tool.chacuo.net/crypt3des]()。其中的模式我们主要了解下ECB和CBC两种简单模式，其它有兴趣可自行查阅。
** ECB模式(Electronic Codebook Book)： **这种模式是将明文分成若干小段，然后对每一段进行单独的加密，每一段之间不受影响，可以单独的对某几段密文进行解密。
** CBC模式(Cipher Block Chaining)： **这种模式是将明文分成若干小段，然后每一段都会和初始向量(上图的iv偏移量)或者上一段的密文进行异或运算后再进行加密，不可以单独解密某一断密文。
** 填充补位： **常用为PKCS5Padding，规则为缺几位就在后面补几位的所缺位数。，比如明文数据为```/x01/x01/x01/x01/x01/x01```6个字节，缺2位补```/x02```，补完位```/x01/x01/x01/x01/x01/x01/x02/x02```。解密后也会按照这个规则进行逆处理。需要注意的是：明文为8位时也需要在后面补充8个```/x08```。
####2. 真实性
客户端有了对称秘钥，就需要考虑如何将秘钥送到服务端，问题跟上面一样：不能以明文形式直接传输，否则还是会被黑客截获到。这里就需要用到非对称加密算法。
** 非对称加密： **加密和解密秘钥不同，分别称为公开秘钥(publicKey)和私有秘钥(privateKey)。两者成对出现，公钥加密只能用私钥解密，而私钥加密也只能用公钥加密。两者不同的是：公钥是公开的，可以随意提供给任何人，而私钥必须保密。特点是保密性好，但是加密速度慢。常见的非对称加密算法有RSA、ECC等；我们了解下常见的RSA算法：
** RSA(Ron Rivest、Adi Shamir、Leonard Adleman)： **1977年由麻省理工学院三人提出，RSA就是他们三个人的姓氏开头字母拼在一起组成的。数学原理是基于大数分解。类似于```100=20x5```，如果只知道100的话，需要多次计算才可以试出20和5两个因子。如果100改为极大的一个数，就非常难去试出真正的结果了。下面是随机生成的一对公私钥:
这是使用公钥加密后结果：
RSA的这种特性就可以保证私钥持有者的真实性，客户端使用公钥加密文件后，黑客就算截获到数据因为没有私钥也是无法解密的。
** Tips： **
+** 不使用对称加密，直接用RSA公私钥进行加密和解密可以吗？ **
答案：不可以，第一是因为RSA加密速度比对称加密要慢几十倍甚至几百倍以上，第二是因为RSA加密后的数据量会变大很多。
+** 由服务端生成对称秘钥，然后用私钥加密，客户端用公钥解密这样来保证对称秘钥安全可行吗？ **
答案：不可行，因为公钥是公开的，任何一个人都可以拿到公钥解密获取对称秘钥。
####3. 完整性
当客户端向服务端发送对称秘钥加密后的文件时，如果被黑客截获，虽然无法解密得到对称秘钥。但是黑客可以用服务端公钥加密一个假的对称秘钥，并用假的对称秘钥加密一份假文件发给服务端，这样服务端会仍然认为是真的客户端发送来的，而并不知道阅读的文件都已经是掉包的了。
这个问题就需要用到散列算法，也可以译为Hash。常见的比如MD4、MD5、SHA-1、SHA-2等。
** 散列算法(哈希算法)： **简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。而且该过程是不可逆的，无法通过摘要获得原文。
** SHA-1(Secure Hash Algorithm 1)： **由美国提出，可以生成一个20字节长度的消息摘要。05年被发现了针对SHA-1的有效攻击方法，已经不再安全。2010年以后建议使用SHA-2和SHA-3替代SHA-1。
** SHA-2(Secure Hash Algorithm 2)： **其下又分为六个不同算法标准：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA512/256。其后面数字为摘要结果的长度，越长的话碰撞几率越小。SHA-224的使用如下图：
客户端通过上面的散列算法可以获取文件的摘要消息，然后用客户端私钥加密后连同加密的文件发给服务端。黑客截获到数据后，他没有服务端私钥无法获取到对称秘钥，也没有客户端私钥无法伪造摘要消息。如果再像上面一样去掉包文件，服务端收到解密得到摘要消息一对比就可以知道文件已经被掉包篡改过了。
这种用私钥对摘要消息进行加密的过程称之为数字签名，它就解决了文件是否被篡改问题，也同时可以确定发送者身份。通常这么定义：
** 加密： **用公钥加密数据时称为加密。
** 签名： **用私钥加密数据时称为签名。
####4. 信任性
我们通过对称加密算法加密文件，通过非对称加密传输对称秘钥，再通过散列算法保证文件没被篡改过和发送者身份。这样就安全了吗？
答案是否定的，因为公钥是要通过网络送到对方的。在这期间如果出现问题会导致客户端收到的公钥并不一定是服务端的真实公钥。常见的** 中间人攻击 **就是例子：
** 中间人攻击MITM(Man-in-the-MiddleAttack)： **攻击者伪装成代理服务器，在服务端发送公钥证书时，篡改成攻击者的。然后收到客户端数据后使用攻击者私钥解密，再篡改后使用攻击者私钥签名并且将攻击者的公钥证书发送给服务器。这样攻击者就可以同时欺骗双方获取到明文。
这个风险就需要通过CA机构对公钥证书进行数字签名绑定公钥和公钥所属人，也就是PKI体系。
** PKI(Privilege Management Infrastructure)： **支持公钥管理并能支持认证、加密、完整性和可追究性的基础设施。可以说整个互联网数据传输都是通过PKI体系进行安全保证的。
** CA(Certificate Authority)： **CA机构就是负责颁发证书的，是一个比较公认的权威的证书发布机构。CA有一个管理标准：WebTrust。只有通过WebTrust国际安全审计认证，根证书才能预装到主流的浏览器而成为一个全球可信的认证机构。比如美国的GlobalSign、VeriSign、DigiCert，加拿大的Entrust。我国的CA金融方面由中国人民银行管理CFCA，非金融CA方面最初由中国电信负责建设。
CA证书申请流程：公司提交相应材料后，CA机构会提供给公司一张证书和其私钥。会把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面，然后用一个指纹算法计算出这些数字证书内容的一个指纹，并把指纹和指纹算法用自己的私钥进行加密。由于浏览器基本都内置了CA机构的根证书，所以可以正确的验证公司证书指纹（验签），就不会有安全警告了。
但是：所有的公司其实都可以发布证书，甚至我们个人都可以随意的去发布证书。但是由于浏览器没有内置我们的根证书，当客户端浏览器收到我们个人发布的证书后，找不到根证书进行验签，浏览器就会直接警告提示，这就是之前12306打开会有警告的原因。这种个人发布的证书，其实可以通过系统设置为受信任的证书去消除这个警告。但是由于这种证书机构的权威性和安全性难以信任，大家最好不要这么做。
我们看一下网络HTTPS的证书信息：
其中比较重要的信息：
签发机构：GlobalSign Root CA；
有效日期：2018-04-03到2019-05-26之间可用；
公钥信息：RSA加密，2048位；
数字签名：带 RSA 加密的 SHA-256 ( 1.2.840.113549.1.1.11 )
绑定域名：再进行HTTPS验证时，如果当前域名和证书绑定域名不一致，也会出现警告；
URI：在线管理地址。如果当前私钥出现了风险，CA机构可以在线吊销该证书。
####5. 不可抵赖性
看起来整个过程都很安全了，但是仍存在一种风险：服务端签名后拒不承认，归咎于故障不履行合同怎么办。
解决方法是采用数字时间戳服务：DTS。
** DTS(digital time-stamp)： **作用就是对于成功的电子商务应用，要求参与交易各方不能否认其行为。一般来说，数字时间戳产生的过程为：用户首先将需要加时间戳的文件用Hash算法运算形成摘要，然后将该摘要发送到DTS。DTS在加入了收到文件摘要的日期和事件信息后再对该文件进行数字签名，然后送达用户。
####6. 再次认证
我们有了数字证书保证了身份的真实性，又有了DTS提供的不可抵赖性。但是还是不能百分百确定使用私钥的就是合法持有者。有可能出现被别人盗用私钥进行交易的风险。
解决这个就需要用到强口令、认证令牌OTP、智能卡、U盾或生物特征等技术对使用私钥的当前用户进行认证，已确定其合法性。我们简单了解下很常见的U盾。
** USB Key(U盾)： **刚出现时外形比较像U盘，安全性能像一面盾牌，取名U盾。其内部有一个只可写不可读的区域存储着用户的私钥(也有公钥证书)，银行同样也拥有一份。当进行交易时，所有涉及到私钥的运算都在U盾内部进行，私钥不会泄露。当交易确认时，交易的详细数据会显示到U盾屏幕上，确认无误后通过物理按键确认就可以成功交易了。就算出现问题黑客也是无法控制U盾的物理按键的，用户可以及时取消避免损失。有的U盾里面还有多份证书，来支持国密算法。
** 国密算法： **国家密码局针对各种算法制定了一些列国产密码算法。具体包括：SM1对称加密算法、SM2公钥算法、SM3摘要算法、SM4对称加密算法、ZUC祖冲之算法等。这样可以对国产固件安全和数据安全进行进一步的安全控制。
## HTTPS分析
有了上面的知识，我们可以尝试去分析下HTTPS的整个过程，用Wireshark截取一次HTTPS报文：
Client Hello: 客户端发送Hello到服务端443端口，里面包含了随机数、客户端支持的加密算法、客户端的TLS版本号等；
Server Hello: 服务端回应Hello到客户端，里面包含了服务端选择的加密套件、随机数等；
Certificate： 服务端向客户端发送证书
服务端计算对称秘钥：通过ECDH算法得到对称秘钥
客户端计算对称秘钥：通过ECDH算法得到对称秘钥
开始用对称秘钥进行加密传输数据
其中我们又遇到了新的算法：DH算法
** DH(Diffie-Hellman)： **1976年由Whitefield与Martin Hellman提出的一个奇妙的秘钥交换协议。这个机制的巧妙在于可以通过安全的方式使双方获得一个相同的秘钥。数学原理是基于原根的性质，如图：
*** DH算法的用处不是为了加密或解密消息，而是用于通信双方安全的交换一个相同的秘钥。 ***
** ECDH： **基于ECC(椭圆曲线密码体制)的DH秘钥交换算法，数学原理是基于椭圆曲线上的离散对数问题。
** ECDHE： **字面少了一个E，E代表了临时。在握手流程中，作为服务器端，ECDH使用证书公钥代替Pb，使用自身私钥代替Xb。这个算法时服务器不发送server key exchange报文，因为发送certificate报文时，证书本身就包含了Pb信息。
##总结
| 算法名称 | 特点 | 用处 | 常用算法名 |
| --- | :--- | :---: | ---: |
| 对称加密 | 速度快，效率高| 用于直接加密文件 | 3DES、AES、RC4 |
| 非对称加密 | 速度相对慢，但是确保安全 | 构建CA体系 | RSA、ECC |
| 散列算法 | 算出的摘要长度固定，不可逆 | 防止文件篡改 | SHA-1、SHA-2 |
| DH算法 | 安全的推导出对称秘钥 | 交换对称秘钥 | ECDH |
----
Ⅱ 如何查看本机能够支持的https加密算法套件
WIN 2008 R2 IIS 7 以上版本
CentOS 6+ OpenSSL 1.0.1c+
Apache 2.4 +
Nginx 1.0.6+
JDK1.7
tomcat7.0.56+
(以上版本都可以）
Ⅲ 如何在反编译的apk中找到加密算法
所谓APK指的是android操作系统的应用程序安装文件。所谓Crack，简单地理解为“破解”。我具体指的是反编译APK文件进行汇编级的代码分析，并修改或插入自己的代码，重新签名打包为APK文件，以达到改变程序原有行为的目的。
由以上的说明可知，我们要Crack一个APK文件，主要流程有三步：反编译、代码分析、重新打包签名。
基本准备
我们需要一些基本的工具进行一些主要的工作。如果你是一个会做Android APK汉化的朋友，那么你应该对这些工具非常熟悉：
第一个工具是android-apktool，A tool for reengineering Android apk files 。这个工具是我们完成APK Crack的核心，利用它实现APK文件的反编译和重新打包。它是Google Code上一个非常着名的开源项目，大家可以在Google Code的网页上获取它和它的Wiki、源码及其他相关信息。
第二个工具是Auto-sign。这个工具实现的是APK打包后的签名工作，属于一个小工具。
除了这些基本工具外，为了更好的分析代码，你可能还需要用到一些其他工具，例如：dex2jar和jd-gui等，这里不做详述。
反编译
如果你是一个经常汉化APK程序的朋友，那么反编译这一步你肯定不会陌生。不过，既然这篇文章侧重于基本流程讲解，那么这一步想来是不能省掉的。所以，觉得罗嗦的朋友，请跳过。首先我们需要有一个待反编译的APK。这里我自己写了一个HelloWorld的APK，代码如下：
package com.zh_weir.helloworld;import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
复制代码
我们通过android-apktool对这个APK进行反编译。对于android-apktool的使用，我就不做太多翻译的工作，直接给出说明文档吧。简单一句话，就是命令行执行。
Apktool v1.3.2 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <[email protected]>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
Usage: apktool [-v|--verbose] COMMAND [...]
COMMANDs are:
d[ecode] [OPTS] <file.apk> [<dir>]
Decode <file.apk> to <dir>.
OPTS:
-s, --no-src
Do not decode sources.
-r, --no-res
Do not decode resources.
-d, --debug
Decode in debug mode. Check project page for more info.
-f, --force
Force delete destination directory.
-t <tag>, --frame-tag <tag>
Try to use framework files tagged by <tag>.
--keep-broken-res
Use if there was an error and some resources were dropped, e.g.:
"Invalid config flags detected. Dropping resources", but you
want to decode them anyway, even with errors. You will have to
fix them manually before building.
b[uild] [OPTS] [<app_path>] [<out_file>]
Build an apk from already decoded application located in <app_path>.
It will automatically detect, whether files was changed and perform
needed steps only.
If you omit <app_path> then current directory will be used.
If you omit <out_file> then <app_path>/dist/<name_of_original.apk>
will be used.
OPTS:
-f, --force-all
Skip changes detection and build all files.
-d, --debug
Build in debug mode. Check project page for more info.
if|install-framework <framework.apk>
Install framework file to your system.
For additional info, see: http://code.google.com/p/android-apktool/
复制代码
通过apktool d HelloWorld.apk的命令，我们就完成了一个简单的APK的反编译工作。得到了一个叫做“HelloWorld”的文件夹。你可以看见文件夹下有Manifest文件，有反编译出的res资源文件。这些东西都是平时汉化特别关心的，而不是我们要注意的重点。我们需要注意的是一个叫做“smali”的文件夹。
仔细观察，你会发现这个文件夹下的文件组织结构和我们的Android工程中java源码的组织结构几乎一致。只不过Java文件被.smali的文件取而代之了。我们用文本编辑器打开这些.smali文件，你会发现它们都是可识别的、并且非常“整齐”的文本文件。
Ⅳ 2019-07-15
检测到远端XFS服务正在运行中漏洞
临时关闭fs.auto服务：
可以通过编辑/etc/inetd.conf文件，重新启动Inetd进程来关闭fs.auto服务：
1. 注释/etc/inetd.conf文件中的如下一行：
#fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs
2. 重新启动inetd进程：
# ps -elf |grep inetd
root 138 1 0 Oct 15 ? 0:00 /usr/sbin/inetd
# kill -1 138
solaris 查找文件 find命令
1. find命令格式
find: [-H | -L] 路径列表 谓词列表
可以使用：man find 查看命令选项。
2. 通过文件名查找法：
如果你把这个文件放在单个的文件夹里面，只要使用常见的“ls"命令就能方便的查找出来，如果知道了某个文件的文件名，而不知道这个文件放到哪个文件夹，甚至是层层套嵌的文件夹里。举例说明，假设你忘记了sshd_config（ssh 服务器 的配置文件）这个文件在系统的哪个目录下，甚至在系统的某个地方也不知道，则这是可以使用如下命令
find / -name sshd_config
这个命令语法看起来很容易就明白了，就是直接在find后面写上 -name，表明要求系统按照文件名查找，最后写上httpd.conf这个目标文件名即可。稍等一会系统会在计算机 屏幕 上显示出查找结果列表：
#find / -name sshd_config
/var/sadm/pkg/SUNWsshdr/save/pspool/SUNWsshdr/reloc/etc/ssh/sshd_config
/etc/ssh/sshd_config
如果输入以上查找命令后系统并没有显示出结果，那么不要以为系统没有执行find/ -name sshd_config 命令，而可能是你的系统中没有安装ssh 服务器 ，这时只要你安装了ssh服务器，然后再使用find / -name sshd_config 就能找到这个配置文件了。
服务器支持 TLS Client-initiated 重协商攻击 (CVE-2011-1473)
SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。
重协商就是大部分TLS连接都以handshake为开始，经过应用数据的交换，最后关闭会话。如果在第一次handshake之后（可能经历了应用数据的交换也可能没有）请求重新协商，就会发起一次新的handshake，对新的安全参数达成一致
关闭命令：ssl renegotiation disable
远端rsh 服务允许部分用户登录。需要禁止rsh 服务 。
方法：
cat /.rhosts 查看是否有 + 号，意思是允许所有其他机器访问。 我们主要VI编辑将+去掉即可。（该配置文件，其做用就是控制访问IP）
因为RSH服务不能控制入访因此我们需要禁用内网所有主机的出访服务
禁用RSH出访服务 svcadm disable svc:/network/shell:default
禁用rlogin服务 svcadm disable svc:/network/login:rlogin
检测到远端rsh 服务正在运行中。禁用RSH 服务，改用SSH 代替 。
方法：
1、vi /.rhosts 去掉其中的+号
2、vi /etc/default/login
CONSOLE=/dev/console 将这一行#注释掉。
因为RSH服务不能控制入访因此我们需要禁用内网所有主机的出访服务
3、禁用RSH出访服务 svcadm disable svc:/network/shell:default
4、禁用rlogin服务 svcadm disable svc:/network/login:rlogin
SSL 3.0 POODLE攻击信息泄露漏洞(CVE-2014-3566)
现场次漏洞只存在于服务器，后又发现此漏洞依赖于服务器的5989端口，可以在防火墙禁用此端口或杀掉此进程
方法一 编辑： vi /etc/sysconfig/iptables
添加：-A INPUT -p tcp --dport 5989 -j DROP
-A INPUT -p tcp --sport 5989 -j DROP
重启网络服务：service iptables restart
方法二 根据netstat –tunlp|grep 5989 查找PID ，pwdxPID查看程序路径，如没问题则可以杀死此进程。
POODLE = Padding Oracle On Downgraded Legacy Encryption.是最新安全漏洞(CVE-2014-3566)的代号，俗称“贵宾犬”漏洞。 此漏洞是针对 SSL 3.0中CBC模式加密算法的一种padding oracle攻击，可以让攻击者获取 SSL 通信中的部分信息明文，如果将明文中的重要部分获取了，比如cookie,session，则信息的安全出现了隐患。
从本质上说，这是 SSL 设计上的缺陷， SSL 先认证再加密是不安全的。
修复措施：
禁用sslv3协议
不同的web server不尽相同。这边列举主流的服务器的禁用方式
Nginx服务器：
注意：nginx和openssl套件版本过低可能会导致无法启用新型加密套件和算法，请升级最新版本。
（openssl1.0.1+版本支持TLS1.1和TLS1.2协议）
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL;
ssl_prefer_server_ciphers on;
apache服务器：
注意：apache和openssl套件版本过低可能会导致无法启用新型加密套件和算法，请升级最新版本。
（openssl1.0.1+版本支持TLS1.1和TLS1.2协议）
apache2.X版本：
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL
SSLHonorCipherOrder on
Tomcat服务器：
JDK版本过低也会带来不安全漏洞，请升级JDK为最新版本。升级JDK风险请安按照系统升级风险酌情考虑。
（先备份再配置，低版本的配置后有启动不了的风险，请升级tomcat和jdk版本，JDK1.7及以上支持TLS1.2协议）
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="keystore/domain.jks" keystorePass="证书密码"
clientAuth="false" sslProtocol="TLS"
ciphers="TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA" />
使用apr的tomcat（windows环境路径请使用“\”，证书文件是for apache压缩包中的三个文件）
maxThreads="150"
protocol="org.apache.coyote.http11.Http11AprProtocol"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
SSLEnabled="true"
SSLProtocol="all -SSLv2 -SSLv3"
SSLCertificateFile="conf/domian.com.crt"
SSLCertificateKeyFile="conf/domian.com.key"
SSLCertificateChainFile="conf/root_bundle.crt"
SSLCipherSuite="ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL" />
Ⅳ 【深度知识】区块链之加密原理图示(加密,签名)
先放一张以太坊的架构图：
在学习的过程中主要是采用单个模块了学习了解的，包括P2P,密码学，网络，协议等。直接开始总结：
秘钥分配问题也就是秘钥的传输问题，如果对称秘钥，那么只能在线下进行秘钥的交换。如果在线上传输秘钥，那就有可能被拦截。所以采用非对称加密，两把钥匙，一把私钥自留，一把公钥公开。公钥可以在网上传输。不用线下交易。保证数据的安全性。
如上图，A节点发送数据到B节点，此时采用公钥加密。A节点从自己的公钥中获取到B节点的公钥对明文数据加密，得到密文发送给B节点。而B节点采用自己的私钥解密。
2、无法解决消息篡改。
如上图，A节点采用B的公钥进行加密，然后将密文传输给B节点。B节点拿A节点的公钥将密文解密。
1、由于A的公钥是公开的，一旦网上黑客拦截消息，密文形同虚设。说白了，这种加密方式，只要拦截消息，就都能解开。
2、同样存在无法确定消息来源的问题，和消息篡改的问题。
如上图，A节点在发送数据前，先用B的公钥加密，得到密文1，再用A的私钥对密文1加密得到密文2。而B节点得到密文后，先用A的公钥解密，得到密文1，之后用B的私钥解密得到明文。
1、当网络上拦截到数据密文2时， 由于A的公钥是公开的，故可以用A的公钥对密文2解密，就得到了密文1。所以这样看起来是双重加密，其实最后一层的私钥签名是无效的。一般来讲，我们都希望签名是签在最原始的数据上。如果签名放在后面，由于公钥是公开的，签名就缺乏安全性。
2、存在性能问题，非对称加密本身效率就很低下，还进行了两次加密过程。
如上图，A节点先用A的私钥加密，之后用B的公钥加密。B节点收到消息后，先采用B的私钥解密，然后再利用A的公钥解密。
1、当密文数据2被黑客拦截后，由于密文2只能采用B的私钥解密，而B的私钥只有B节点有，其他人无法机密。故安全性最高。
2、当B节点解密得到密文1后， 只能采用A的公钥来解密。而只有经过A的私钥加密的数据才能用A的公钥解密成功，A的私钥只有A节点有，所以可以确定数据是由A节点传输过来的。
经两次非对称加密，性能问题比较严重。
基于以上篡改数据的问题，我们引入了消息认证。经过消息认证后的加密流程如下：
当A节点发送消息前，先对明文数据做一次散列计算。得到一个摘要, 之后将照耀与原始数据同时发送给B节点。当B节点接收到消息后，对消息解密。解析出其中的散列摘要和原始数据，然后再对原始数据进行一次同样的散列计算得到摘要1, 比较摘要与摘要1。如果相同则未被篡改，如果不同则表示已经被篡改。
在传输过程中，密文2只要被篡改，最后导致的hash与hash1就会产生不同。
无法解决签名问题，也就是双方相互攻击。A对于自己发送的消息始终不承认。比如A对B发送了一条错误消息，导致B有损失。但A抵赖不是自己发送的。
在(三)的过程中，没有办法解决交互双方相互攻击。什么意思呢？ 有可能是因为A发送的消息，对A节点不利，后来A就抵赖这消息不是它发送的。
为了解决这个问题，故引入了签名。这里我们将(二)-4中的加密方式，与消息签名合并设计在一起。
在上图中，我们利用A节点的私钥对其发送的摘要信息进行签名，然后将签名+原文，再利用B的公钥进行加密。而B得到密文后，先用B的私钥解密，然后 对摘要再用A的公钥解密，只有比较两次摘要的内容是否相同。这既避免了防篡改问题，有规避了双方攻击问题。因为A对信息进行了签名，故是无法抵赖的。
为了解决非对称加密数据时的性能问题，故往往采用混合加密。这里就需要引入对称加密，如下图:
在对数据加密时，我们采用了双方共享的对称秘钥来加密。而对称秘钥尽量不要在网络上传输，以免丢失。这里的共享对称秘钥是根据自己的私钥和对方的公钥计算出的，然后适用对称秘钥对数据加密。而对方接收到数据时，也计算出对称秘钥然后对密文解密。
以上这种对称秘钥是不安全的，因为A的私钥和B的公钥一般短期内固定，所以共享对称秘钥也是固定不变的。为了增强安全性，最好的方式是每次交互都生成一个临时的共享对称秘钥。那么如何才能在每次交互过程中生成一个随机的对称秘钥，且不需要传输呢？
那么如何生成随机的共享秘钥进行加密呢？
对于发送方A节点，在每次发送时，都生成一个临时非对称秘钥对，然后根据B节点的公钥 和 临时的非对称私钥 可以计算出一个对称秘钥(KA算法-Key Agreement)。然后利用该对称秘钥对数据进行加密，针对共享秘钥这里的流程如下：
对于B节点，当接收到传输过来的数据时，解析出其中A节点的随机公钥，之后利用A节点的随机公钥 与 B节点自身的私钥 计算出对称秘钥(KA算法)。之后利用对称秘钥机密数据。
对于以上加密方式，其实仍然存在很多问题，比如如何避免重放攻击(在消息中加入 Nonce )，再比如彩虹表(参考 KDF机制解决 )之类的问题。由于时间及能力有限，故暂时忽略。
那么究竟应该采用何种加密呢？
主要还是基于要传输的数据的安全等级来考量。不重要的数据其实做好认证和签名就可以，但是很重要的数据就需要采用安全等级比较高的加密方案了。
密码套件 是一个网络协议的概念。其中主要包括身份认证、加密、消息认证(MAC)、秘钥交换的算法组成。
在整个网络的传输过程中，根据密码套件主要分如下几大类算法：
秘钥交换算法：比如ECDHE、RSA。主要用于客户端和服务端握手时如何进行身份验证。
消息认证算法：比如SHA1、SHA2、SHA3。主要用于消息摘要。
批量加密算法：比如AES, 主要用于加密信息流。
伪随机数算法：例如TLS 1.2的伪随机函数使用MAC算法的散列函数来创建一个 主密钥 ——连接双方共享的一个48字节的私钥。主密钥在创建会话密钥（例如创建MAC）时作为一个熵来源。
在网络中，一次消息的传输一般需要在如下4个阶段分别进行加密，才能保证消息安全、可靠的传输。
握手/网络协商阶段：
在双方进行握手阶段，需要进行链接的协商。主要的加密算法包括RSA、DH、ECDH等
身份认证阶段：
身份认证阶段，需要确定发送的消息的来源来源。主要采用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA签名)等。
消息加密阶段：
消息加密指对发送的信息流进行加密。主要采用的加密方式包括DES、RC4、AES等。
消息身份认证阶段/防篡改阶段：
主要是保证消息在传输过程中确保没有被篡改过。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC ：Elliptic Curves Cryptography，椭圆曲线密码编码学。是一种根据椭圆上点倍积生成 公钥、私钥的算法。用于生成公私秘钥。
ECDSA ：用于数字签名,是一种数字签名算法。一种有效的数字签名使接收者有理由相信消息是由已知的发送者创建的，从而发送者不能否认已经发送了消息(身份验证和不可否认)，并且消息在运输过程中没有改变。ECDSA签名算法是ECC与DSA的结合，整个签名过程与DSA类似，所不一样的是签名中采取的算法为ECC，最后签名出来的值也是分为r,s。 主要用于身份认证阶段 。
ECDH ：也是基于ECC算法的霍夫曼树秘钥，通过ECDH，双方可以在不共享任何秘密的前提下协商出一个共享秘密，并且是这种共享秘钥是为当前的通信暂时性的随机生成的，通信一旦中断秘钥就消失。 主要用于握手磋商阶段。
ECIES： 是一种集成加密方案,也可称为一种混合加密方案，它提供了对所选择的明文和选择的密码文本攻击的语义安全性。ECIES可以使用不同类型的函数：秘钥协商函数(KA)，秘钥推导函数(KDF)，对称加密方案(ENC)，哈希函数(HASH), H-MAC函数(MAC)。
ECC 是椭圆加密算法，主要讲述了按照公私钥怎么在椭圆上产生，并且不可逆。 ECDSA 则主要是采用ECC算法怎么来做签名， ECDH 则是采用ECC算法怎么生成对称秘钥。以上三者都是对ECC加密算法的应用。而现实场景中，我们往往会采用混合加密(对称加密，非对称加密结合使用，签名技术等一起使用)。 ECIES 就是底层利用ECC算法提供的一套集成(混合)加密方案。其中包括了非对称加密，对称加密和签名的功能。
<meta charset="utf-8">
这个先订条件是为了保证曲线不包含奇点。
所以，随着曲线参数a和b的不断变化，曲线也呈现出了不同的形状。比如:
所有的非对称加密的基本原理基本都是基于一个公式 K = k G。其中K代表公钥，k代表私钥，G代表某一个选取的基点。非对称加密的算法 就是要保证 该公式 不可进行逆运算( 也就是说G/K是无法计算的 )。 *
ECC是如何计算出公私钥呢？这里我按照我自己的理解来描述。
我理解，ECC的核心思想就是：选择曲线上的一个基点G，之后随机在ECC曲线上取一个点k(作为私钥)，然后根据k G计算出我们的公钥K。并且保证公钥K也要在曲线上。*
那么k G怎么计算呢？如何计算k G才能保证最后的结果不可逆呢？这就是ECC算法要解决的。
首先，我们先随便选择一条ECC曲线，a = -3, b = 7 得到如下曲线：
在这个曲线上，我随机选取两个点，这两个点的乘法怎么算呢？我们可以简化下问题，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那么我们只要能在曲线上计算出加法，理论上就能算乘法。所以，只要能在这个曲线上进行加法计算，理论上就可以来计算乘法，理论上也就可以计算k*G这种表达式的值。
曲线上两点的加法又怎么算呢？这里ECC为了保证不可逆性，在曲线上自定义了加法体系。
现实中，1+1=2，2+2=4，但在ECC算法里，我们理解的这种加法体系是不可能。故需要自定义一套适用于该曲线的加法体系。
ECC定义，在图形中随机找一条直线，与ECC曲线相交于三个点(也有可能是两个点)，这三点分别是P、Q、R。
那么P+Q+R = 0。其中0 不是坐标轴上的0点，而是ECC中的无穷远点。也就是说定义了无穷远点为0点。
同样，我们就能得出 P+Q = -R。 由于R 与-R是关于X轴对称的，所以我们就能在曲线上找到其坐标。
P+R+Q = 0, 故P+R = -Q , 如上图。
以上就描述了ECC曲线的世界里是如何进行加法运算的。
从上图可看出，直线与曲线只有两个交点，也就是说 直线是曲线的切线。此时P,R 重合了。
也就是P = R, 根据上述ECC的加法体系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0
于是乎得到 2 P = -Q (是不是与我们非对称算法的公式 K = k G 越来越近了)。
于是我们得出一个结论，可以算乘法，不过只有在切点的时候才能算乘法，而且只能算2的乘法。
假若 2 可以变成任意个数进行想乘，那么就能代表在ECC曲线里可以进行乘法运算，那么ECC算法就能满足非对称加密算法的要求了。
那么我们是不是可以随机任何一个数的乘法都可以算呢？ 答案是肯定的。 也就是点倍积 计算方式。
选一个随机数 k, 那么k * P等于多少呢？
我们知道在计算机的世界里，所有的都是二进制的，ECC既然能算2的乘法，那么我们可以将随机数k描 述成二进制然后计算。假若k = 151 = 10010111
由于2 P = -Q 所以 这样就计算出了k P。 这就是点倍积算法 。所以在ECC的曲线体系下是可以来计算乘法，那么以为这非对称加密的方式是可行的。
至于为什么这样计算 是不可逆的。这需要大量的推演，我也不了解。但是我觉得可以这样理解：
我们的手表上，一般都有时间刻度。现在如果把1990年01月01日0点0分0秒作为起始点，如果告诉你至起始点为止时间流逝了 整1年，那么我们是可以计算出现在的时间的，也就是能在手表上将时分秒指针应该指向00：00：00。但是反过来，我说现在手表上的时分秒指针指向了00：00：00,你能告诉我至起始点算过了有几年了么？
ECDSA签名算法和其他DSA、RSA基本相似，都是采用私钥签名，公钥验证。只不过算法体系采用的是ECC的算法。交互的双方要采用同一套参数体系。签名原理如下：
在曲线上选取一个无穷远点为基点 G = (x,y)。随机在曲线上取一点k 作为私钥， K = k*G 计算出公钥。
签名过程：
生成随机数R, 计算出RG.
根据随机数R,消息M的HASH值H,以及私钥k, 计算出签名S = (H+kx)/R.
将消息M,RG,S发送给接收方。
签名验证过程：
接收到消息M, RG,S
根据消息计算出HASH值H
根据发送方的公钥K,计算 HG/S + xK/S, 将计算的结果与 RG比较。如果相等则验证成功。
公式推论：
HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG
在介绍原理前，说明一下ECC是满足结合律和交换律的，也就是说A+B+C = A+C+B = (A+C)+B。
这里举一个WIKI上的例子说明如何生成共享秘钥，也可以参考 Alice And Bob 的例子。
Alice 与Bob 要进行通信，双方前提都是基于 同一参数体系的ECC生成的 公钥和私钥。所以有ECC有共同的基点G。
生成秘钥阶段：
Alice 采用公钥算法 KA = ka * G ，生成了公钥KA和私钥ka, 并公开公钥KA。
Bob 采用公钥算法 KB = kb * G ，生成了公钥KB和私钥 kb, 并公开公钥KB。
计算ECDH阶段：
Alice 利用计算公式 Q = ka * KB 计算出一个秘钥Q。
Bob 利用计算公式 Q' = kb * KA 计算出一个秘钥Q'。
共享秘钥验证：
Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'
故 双方分别计算出的共享秘钥不需要进行公开就可采用Q进行加密。我们将Q称为共享秘钥。
在以太坊中，采用的ECIEC的加密套件中的其他内容：
1、其中HASH算法采用的是最安全的SHA3算法 Keccak 。
2、签名算法采用的是 ECDSA
3、认证方式采用的是 H-MAC
4、ECC的参数体系采用了secp256k1, 其他参数体系 参考这里
H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：
在 以太坊 的 UDP通信时(RPC通信加密方式不同)，则采用了以上的实现方式，并扩展化了。
首先，以太坊的UDP通信的结构如下：
其中，sig是 经过 私钥加密的签名信息。mac是可以理解为整个消息的摘要， ptype是消息的事件类型，data则是经过RLP编码后的传输数据。
其UDP的整个的加密，认证，签名模型如下：
Ⅵ 温故而知新之HTTPS
对于HTTPS其实很早之前就有过学习，但对其一直是一知半解，知道的并不深入全面，因此用了些时间，好好地阅读了极客时间关于HTTPS的一些专栏，并总结一下尝试着用自己的话来描述一下。
HTTP最初的目的：传输超文本文件，因此一直是明文传输文件，而且不安全。由于是明文传输，所以就很容易被中间人所截取，一切通信的内容也被这个中间人所掌握。这也就是常说的中间人攻击。
那如何定义通信过程是安全的呢：机密性，完整性，身份验证以及不可否认：
机密性：简单来说就是数据是加密过的，除了参与通信之外的人都是都是看不了的。
完整性：数据在通信的过程中是完整的，没加经过篡改的。
身份认证：通信双方可以验证对方的真实身份
不可否认：不能否认已经发生过的行为
因为是明文传输，所以在一些对安全要求高的场景就不能很好的满足需求，因此在原有的基础上引入了加密方案，在TCP和HTTP之间加入了一个安全层SSL/TLS
SSL全名叫Secure Sockets Layer中文名叫 安全套接层，在 OSI 模型中储运第五层会话层的位置。这玩意儿是由网景公司所发明，并在其发展到 V3 的时候被 IETF 改名为 TLC（Transport Layer Security），并对其进行标准化。而 TLS 发展到现在也经历了三个版本，最新的版本是2018年所制定的，牢牢的将密码学的发展与当今互联网的现状相结合，持续提高安全与性能，因此也成为信息安全领域的权威标准。
而它的职责也很简单：
当浏览器客户端和服务端在使用 TLS 进行通信时，需要选择一组合理的加密算法来实现安全通信，而这些算法的组合通常被称为：加密套件。它的命名是很规范的，基本形式就是：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法。其中，签名算法可以进行身份验证，摘要算法可以保证数据的完整性，而对称加密算法则可以保证数据的机密性。（值得注意的是，在2019年不安全的 TLS 1.0 和 1.1 默认被禁用（ Safari TP 91 、Google Chrome 72+、Firefox Nightly）
前面我们提到，HTTP协议在进行传输的时候是通过明文进行传输的，因此不安全。那么如果需要保证传输信息的机密性，最简单的方法不外于将其进行加密，这样第三方的人在拿到这些信息的时候，也就不能获取信息里面的内容了。因此这就引入了加密的第一个概念：对称加密。
对称加密其实很简单：加密和解密都使用的是相同的密钥，是对称的，这里的密钥就是用于解开加密信息的钥匙。
简单来说就是客户端会给服务端发送它支持的加密的方法的列表，以及一个随机数，然后服务器端在接受到这些东西后，会从客户端所支持的加密方法列表中选取一种，然后同时生成一个随机数给客户端，这样两端就都确定了加密方法和随机数，也就可以通过这些信息来生成对应的密钥了。这样做的话即使黑客在获取到浏览器与服务器所传输的信息，得到的也只是一串乱码，而他也没有相应的密钥，也就保证了信息传输的机密性。
TLS中所提供的对称加密算法有很多，其中最常用的当属 AES（Advanced Encryption Standard）既高级加密标准，密钥的长度可以是128，192，256，是当今用的最为广泛的对称加密算法。当然除了上面这个AES之外，我们国家也存在这自己的一套对称加密算法：SM1 和 SM4。其中SM1算法不公开，属于国家机密，而 SM4 则是公开的，可以自行使用，这两个算法的最大的优势就在于：国家支持！
对称加密还有一个分组的概念，他可以让算法用固定的长度的密钥加密任意长度的明文，从而将密钥转化为密文。最新的分组模式叫做AEAD，在加密的同时还增加了认证的功能。
对称加密就是通过上面的这些东西，来完成一个简单却安全的加密方式的。
对称加密看起来的确是解决了我们所说的安全要素中的机密性的要求，但它仍然存在一个致命的漏洞就是：密钥交互的方式仍然是明文的。也正是为了解决密钥安全的问题，我们就需要使用非堆成加密的方法，那什么是非堆成加密呢？非对称加密简单来说就是有两把私钥，一把是公钥，可以公开给任何人使用，一把是私钥，需要严格保密。这就形成了一个非对称性。具体举个栗子来讲就是：有 A、B 两把密钥，如果你用 A 密钥来加密，那么只能使用 B 密钥来解密；反过来，如果你要 B 密钥来加密，那么只能用 A 密钥来解密。
非对称加密除了可以对信息进行加密外，很多非对称加密算法还有签名的功能，这样就可以提供身份认证，保证通信双方可以确定对面的身份。
而从实现上来讲，所有的非对称加密算法，都是基于各种数学难题来设计实现的，这些难题的特点在于：正向计算很简单，反向推倒是无解的。其中比较经典的非对称加密算法包括：RSA，ECC以及SM2。
RSA 是所使用的数学难题是：两个大的质数相乘的结果很容易计算，但根据这个结果去做质因分解得到原先的两个质数，则需要很大的计算量。就比如这个：
https://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/2019-December/001139.html 。
前段时间美国一群大佬宣布，240哥十进制的整数分解成功，找到了它的两个大质数因子，不过这个成本也是很大的。
ECC和 SM2 都是是基于椭圆曲线的数学难题设计的。普遍的观点认为，椭圆曲线的难度高于大质数难题，160 位密钥的 ECC 加密强度，相当于 1088 位密钥的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，因此对于互联网行业来讲吸引力也是相当大的。而SM2除了加密强度和国际标准和ECC差不多以外，还属于国家所支持的非对称加密算法。
需要注意的是，非对称加密的安全性上虽然可以满足我们的需求，但它却存在这一个比较大的问题就是L：性能。由于非对称加密在所需要的算法运算非常复杂，因此在性能上得不到很好的保证。也正是由于这个原因，现在的TLS主要采用的是一种叫混合加密的方式来进行加密。
混合加密其实很简单，就是使用非对称加密的方式，解决密钥交换的问题，然后用随机数产生对称算法使用的会话密钥，在对其使用公钥加密，并传送给通信对象。通信对象拿到密文后用私钥解开并取出会话密钥。这样就是实现了堆成密钥的安全交换了，后续就可以使用这个对称密钥来进行对称加密。
在前面我们有提到过安全的几大要素，其中机密性我们可以通过上面的对称加密 + 非对称加密来解决。而在完整性方面，我们则需要使用摘要算法来解决。
简单理解，我们可以将摘要算法理解为一种特殊的压缩算法，他可以将任意长度的数据压缩成固定长度且独一无二的摘要字符串，且这个加密的过程也是单向的，加密后的数据无法解密，不能从摘要中反向推出原文。
https://time.geekbang.org/column/article/176569
https://time.geekbang.org/column/intro/189 ——安全篇