Skip to content

Commit 010d494

Browse files
committed
updates
1 parent c61ce06 commit 010d494

9 files changed

+162
-76
lines changed

第9章 安全加密/Https扫盲贴.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ HTTPS相对于HTTP有哪些不同呢?其实就是在HTTP跟TCP中间加多了
5858
- 登陆用户:小明
5959
- 授权网站:某知名社交网站(以下简称XX)
6060

61-
小明都是某知名社交网站XX的用户,XX出于安全考虑在登陆的地方用了非对称加密。小明在登陆界面敲入账号、密码,点击“登陆”。于是,浏览器利用公钥对小明的账号密码进行了加密,并向XX发送登陆请求。XX的登陆授权程序通过私钥,将账号、密码解密,并验证通过。之后,将小明的个人信息(含隐私),通过私钥加密后,传输回浏览器。浏览器通过公钥解密数据,并展示给小明。
61+
小明是某知名社交网站XX的用户,XX出于安全考虑在登陆的地方用了非对称加密。小明在登陆界面敲入账号、密码,点击“登陆”。于是,浏览器利用公钥对小明的账号密码进行了加密,并向XX发送登陆请求。XX的登陆授权程序通过私钥,将账号、密码解密,并验证通过。之后,将小明的个人信息(含隐私),通过私钥加密后,传输回浏览器。浏览器通过公钥解密数据,并展示给小明。
6262

6363
- 步骤一: 小明输入账号密码 --> 浏览器用公钥加密 --> 请求发送给XX
6464
- 步骤二: XX用私钥解密,验证通过 --> 获取小明社交数据,用私钥加密 --> 浏览器用公钥解密数据,并展示。
@@ -76,7 +76,7 @@ HTTPS相对于HTTP有哪些不同呢?其实就是在HTTP跟TCP中间加多了
7676

7777
### 问题一:公钥如何获取
7878

79-
浏览器是怎么获得XX的公钥的?当然,小明可以自己去网上查,XX也可以将公钥贴在自己的主页。然而,对于一个动不动就成败上千万的社交网站来说,会给用户造成极大的不便利,毕竟大部分用户都不知道“公钥”是什么东西。
79+
浏览器是怎么获得XX的公钥的?当然,小明可以自己去网上查,XX也可以将公钥贴在自己的主页。然而,对于一个动不动就成百上千万的社交网站来说,会给用户造成极大的不便利,毕竟大部分用户都不知道“公钥”是什么东西。
8080

8181
### 问题二:数据传输仅单向安全
8282

@@ -103,7 +103,7 @@ HTTPS相对于HTTP有哪些不同呢?其实就是在HTTP跟TCP中间加多了
103103
强调两点:
104104

105105
1. 可以颁发证书的CA有很多(国内外都有)。
106-
2. 只有少数CA被认为是权威、公正的,这些CA颁发的证书,浏览器才认为是信得过的。比如**VeriSign**。(CA自己伪造证书的事情也不是没发生过。。。
106+
2. 只有少数CA被认为是权威、公正的,这些CA颁发的证书,浏览器才认为是信得过的。比如**VeriSign**。(CA自己伪造证书的事情也不是没发生过)
107107

108108
证书颁发的细节这里先不展开,可以先简单理解为,网站向CA提交了申请,CA审核通过后,将证书颁发给网站,用户访问网站的时候,网站将证书给到用户。
109109

@@ -320,4 +320,4 @@ example: sha256WithRSAEncryption
320320

321321
## 写在后面
322322

323-
科普性文章,部分内容不够严谨,如有错漏请指出 :)
323+
科普性文章,部分内容不够严谨,如有错漏请指出

第9章 安全加密/Https编程.md

Lines changed: 15 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -6,22 +6,22 @@
66
4. [Java安全加密:数字签名和数字证书](http://blog.csdn.net/axi295309066/article/details/52494832)
77
5. [Java安全加密:Https编程](http://blog.csdn.net/axi295309066/article/details/52494902)
88

9-
## **概述**
10-
**SSL**(Secure Sockets Layer **安全套接层**),为网景公司(Netscape)所研发,用以保障在Internet 上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取及窃听。一般通用之规格为40 bit 之安全标准,美国则已推出128 bit 之更高安全标准,但限制出境。只要3.0 版本以上之I.E.或Netscape 浏览器即可支持SSL。
9+
## 概述
10+
SSL(Secure Sockets Layer 安全套接层),为网景公司(Netscape)所研发,用以保障在Internet 上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取及窃听。一般通用之规格为40 bit 之安全标准,美国则已推出128 bit 之更高安全标准,但限制出境。只要3.0 版本以上之I.E.或Netscape 浏览器即可支持SSL。
1111

12-
**TLS**(Transport Layer Security **传输层安全**),用于在两个通信应用程序之间提供保密性和数据完整性。TLS 是SSL 的标准化后的产物,有1.0 ,1.1 ,1.2 三个版本,默认使用1.0。TLS1.0 和SSL3.0 几乎没有区别,事实上我们现在用的都是TLS,但因为历史上习惯了SSL 这个称呼。
12+
TLS(Transport Layer Security 传输层安全),用于在两个通信应用程序之间提供保密性和数据完整性。TLS 是SSL 的标准化后的产物,有1.0 ,1.1 ,1.2 三个版本,默认使用1.0。TLS1.0 和SSL3.0 几乎没有区别,事实上我们现在用的都是TLS,但因为历史上习惯了SSL 这个称呼。
1313

14-
### **SSL 通信简单图示**
14+
### SSL 通信简单图示
1515

1616
![ssl](http://img.blog.csdn.net/20160910142930760)
1717

18-
### **SSL 通信详细图示**
18+
### SSL 通信详细图示
1919

2020
![ssl](http://img.blog.csdn.net/20160910143017261)
2121

22-
当请求使用自签名证书的网站数据时,例如请求12306 的客运服务页面:https://kyfw.12306.cn/otn/,则会报下面的错误,原因是客户端的根认证机构不能识别该证书错误信息:unable to find valid certification path to requested target
22+
当请求使用自签名证书的网站数据时,例如请求12306 的客运服务页面:https://kyfw.12306.cn/otn/ ,则会报下面的错误,原因是客户端的根认证机构不能识别该证书错误信息:unable to find valid certification path to requested target
2323

24-
## **解决方案1**
24+
## 解决方案1
2525
一个证书可不可信,是由TrustManager 决定的,所以我们只需要自定义一个什么都不做的TrustManager即可,服务器出示的所有证书都不做校验,一律放行。
2626

2727
```java
@@ -42,7 +42,7 @@ HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
4242
System.out.println(Util.inputstream2String(in));
4343
}
4444

45-
/**
45+
/
4646
* 自定义一个什么都不做的信任管理器,所有证书都不做校验,一律放行
4747
*/
4848
private static class EmptyX509TrustManager implements X509TrustManager{
@@ -62,7 +62,7 @@ HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
6262
}
6363
}
6464
```
65-
## **解决方案2**
65+
## 解决方案2
6666
12306 服务器出示的证书是中铁集团SRCA 给他颁发的,所以SRCA 的证书是能够识别12306 的证书的,所以只需要把SRCA 证书导入系统的KeyStore 里,之后交给TrustManagerFactory 进行初始化,则可把SRCA 添加至根证书认证机构,之后校验的时候,SRCA 对12306 证书校验时就能通过认证。
6767

6868
这种解决方案有两种使用方式:一是直接使用SRCA.cer 文件,二是使用改文件的RFC 格式数据,将其写在代码里。
@@ -116,7 +116,7 @@ InputStream in = conn.getInputStream();
116116
System.out.println(Util.inputstream2String(in));
117117
}
118118
```
119-
## **Android 里的 https 请求**
119+
## Android 里的 https 请求
120120
把scra.cer 文件考到assets 或raw 目录下,或者直接使用证书的RFC 格式,接下来的做法和java工程代码一样
121121

122122
```java
@@ -150,7 +150,7 @@ InputStream in = urlConnection.getInputStream();
150150
copyInputStreamToOutputStream(in, System.out);
151151

152152
```
153-
## **双向证书验证**
153+
## 双向证书验证
154154

155155
```java
156156
CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
@@ -172,10 +172,10 @@ keyManagerFactory.init(clientKeyStore, "123456".toCharArray());
172172
sslContext.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrustManagers(), new SecureRandom());
173173

174174
```
175-
## **Nogotofail**
175+
## Nogotofail
176176
网络流量安全测试工具,Google的开源项目:https://github.com/google/nogotofail
177177

178-
## **Android安全加密专题总结**
178+
## 安全加密专题总结
179179

180180
以上学习所有内容,对称加密、非对称加密、消息摘要、数字签名等知识都是为了理解数字证书工作原理而作为一个预备知识。数字证书是密码学里的终极武器,是人类几千年历史总结的智慧的结晶,只有在明白了数字证书工作原理后,才能理解Https 协议的安全通讯机制。最终才能在SSL 开发过程中得心应手。
181181

@@ -196,3 +196,5 @@ sslContext.init(keyManagerFactory.getKeyManagers(), trustManagerFactory.getTrust
196196
- 知道对称加密、非对称加密、消息摘要、数字签名、数字证书是为了解决什么问题而出现的
197197
- 了解SSL 通讯流程
198198
- 实际开发里怎样请求Https 的接口
199+
200+
![](img/安全加密.png)
81.4 KB
Loading
497 KB
Loading
18.3 KB
Loading

第9章 安全加密/和安全有关的那些事.md

Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -16,19 +16,19 @@
1616

1717
![图1.安全技术堆栈](http://my.csdn.net/uploads/201205/21/1337566646_9367.png)
1818

19-
## 从非对称密钥加密与数字摘要技术谈起
19+
## 从非对称密钥加密与数字摘要技术谈起
2020

2121
### 什么是“非对称密钥加解密”技术
2222

2323
对于一份数据,通过一种[算法](http://lib.csdn.net/base/datastructure),基于传入的密钥(一串由数字或字符组成的字符串,也称“key”),将明文数据转换成了不可阅读的密文,这是众所周知的“加密”,同样的,密文到达目的地后,需要再以相应的算法,配合一个密钥,将密文再解密成明文,这就是“解密”。如果加密和解密使用的是同一个密钥,那么这就是“对称密钥加解密”(最常见的对称加密算法是DES)。如果加密和解密使用的是两个不同的密钥,那么这就是“非对称密钥加解密”(最常用的非对称加密算法是RSA)。这两个不同的密钥一个叫作公开密钥(publickey)另一个叫私有密钥(privatekey),公开密钥对外公开,任何人均可获取,而私有密钥则由自己保存,其实公钥和私钥并没有什么不同之处,公钥之所以成为公钥是因为它会被公开出来,产生任意份拷贝,供任何人获取,而只有服务主机持有唯一的一份私钥,从这种分发模式上看,我们不难看出其中的用意,这种分发模式实际上是Web站点多客户端(浏览器)与单一服务器的网络拓扑所决定的,多客户端意味着密钥能被复制和公开获取,单一服务器意味着密钥被严格控制,只能由本服务器持有,这实际上也是后面要提到的之所以能通过数据证书确定信任主机的重要原因之一。如果我们跳出web站点的拓扑环境,其实就没有什么公钥与私钥之分了,比如,对于那些使用以密钥为身份认证的SSH主机,往往是为每一个用户单独生成一个私钥分发给他们自己保存,SSH主机会保存一份公钥,公钥私钥各有一份,都不会公开传播。
2424

2525
### 什么是“数字摘要“
2626

27-
这个非常简单,我们在下载文件的时候经常会看到有的下载站点也提供下载文件的“数字摘要“,供下载者验证下载后的文件是否完整,或者说是否和服务器上的文件”一模一样“。其实,数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度(128位)的密文,这一串密文又称为数字指纹,它有固定的长度,而且不同的明文摘要成密文,其结果总是不同的,儿同样的明文其摘要必定一致。 因此,“数字摘要“叫”数字指纹“可能会更贴切一些。“数字摘要“是https能确保数据完整性和防篡改的根本原因。
27+
这个非常简单,我们在下载文件的时候经常会看到有的下载站点也提供下载文件的“数字摘要“,供下载者验证下载后的文件是否完整,或者说是否和服务器上的文件”一模一样“。其实,数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度(128位)的密文,这一串密文又称为数字指纹,它有固定的长度,而且不同的明文摘要成密文,其结果总是不同的, 同而样的明文其摘要必定一致。 因此,“数字摘要“叫”数字指纹“可能会更贴切一些。“数字摘要“是https能确保数据完整性和防篡改的根本原因。
2828

2929
## 数字签名--水到渠成的技术
3030

31-
让我们来看看有了“非对称密钥加解密”和“数字摘要“两项技术之后,我们能做些什么呢?假如发送方想把一份报文发送给接收方,在发送报文前,发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私人密钥对这个摘要进行加密,这个加密后的摘要将作为报文的”签名“和报文一起发送给接收方,接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要,接着再用发送方的公用密钥来对报文附加的数字签名进行解密,如果这两个摘要相同、那么接收方就能确认报文是从发送方发送且没有被遗漏和修改过!这就是结合“非对称密钥加解密”和“数字摘要“技术所能做的事情,这也就是人们所说的“数字签名”技术。在这个过程中,对传送数据生成摘要并使用私钥进行加密地过程就是生成”数字签名“的过程,经过加密的数字摘要,就是人们所说的”数字签名“!
31+
让我们来看看有了“非对称密钥加解密”和“数字摘要“两项技术之后,我们能做些什么呢?假如发送方想把一份报文发送给接收方,在发送报文前,发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私人密钥对这个摘要进行加密,这个加密后的摘要将作为报文的”签名“和报文一起发送给接收方,接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要,接着再用发送方的公用密钥来对报文附加的数字签名进行解密,如果这两个摘要相同、那么接收方就能确认报文是从发送方发送且没有被遗漏和修改过!这就是结合“非对称密钥加解密”和“数字摘要“技术所能做的事情,这也就是人们所说的“数字签名”技术。在这个过程中,对传送数据生成摘要并使用私钥进行加密的过程就是生成”数字签名“的过程,经过加密的数字摘要,就是人们所说的”数字签名“!
3232

3333
数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用,它将摘要信息用发送者的私钥加密,与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息,然后用HASH函数对收到的原文产生一个摘要信息,与解密的摘要信息对比。如果相同,则说明收到的信息是完整的,在传输过程中没有被修改,否则说明信息被修改过,因此数字签名能够验证信息的完整性。(注意,数字签名只能验证数据的完整性,数据本身是否加密不属于数字签名的控制范围)
3434

@@ -64,16 +64,18 @@ SSL协议主要确保了以下安全问题:
6464

6565
### HTTPS的劣势
6666

67-
https的主要缺点就是性能问题。造成https性能低于http的原因有两个:
68-
1.对数据进行加解密决定了它比http慢。
67+
https的主要缺点就是性能问题。造成https性能低于http的原因有两个:
68+
69+
1.对数据进行加解密决定了它比http慢。
6970
2.另外一个重要原因的是https禁用了缓存。
71+
7072
相关[测试](http://lib.csdn.net/base/softwaretest)数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。因此对于一个网站来说,只有那对那些安全要求极高的的数据才会选择使用https进行传输。
7173

7274
## 周边话题
7375

7476
### 网络安全和应用程序的安全控制两者之间有什么关系?
7577

76-
网络安全和一个应用程序自身的安全控制之间并没有太多直接的交集,应该说两者的关注点不在一起,前者主要解决的是“传输过程”中的安全问题,即确认信任主机和防止泄密及篡改。而一个应用程序的安全控制是指在请求到达后,应用程序自身对请求进行的安全检查,这种“检查”主要涉及两个方面:Authentication和Authorization,这也是所有应用程序安全控制方面要完成了两个重要任务。关于Authentication和Authorization,详细一点说,Authentication就是:
78+
网络安全和一个应用程序自身的安全控制之间并没有太多直接的交集,应该说两者的关注点不在一起,前者主要解决的是“传输过程”中的安全问题,即确认信任主机和防止泄密及篡改。而一个应用程序的安全控制是指在请求到达后,应用程序自身对请求进行的安全检查,这种“检查”主要涉及两个方面:Authentication(身份验证)和Authorization(授权),这也是所有应用程序安全控制方面要完成了两个重要任务。关于Authentication和Authorization,详细一点说,Authentication就是:
7779

7880
- 从访问者提交的身份信息中,确认当前的访问者是否是本系统的合法的用户,也就是对访问者进行“身份认证”。说得更直白些就是,核实一下当前这个访问者是不是我的用户,是就让他访问,不是就拒绝。所以说,我们一般的系统登录过程就是一个“Authentication”的过程!
7981

0 commit comments

Comments
 (0)