Tag Archives: SSL

[root@lala ~]# openssl req -out www_cheapssl_cn.csr -new -sha256 -newkey rsa:2048 -nodes -keyout www_cheapssl_cn.key
Generating a 2048 bit RSA private key
……………………………………………………………….+++
……………………………………………+++
writing new private key to ‘www_cheapssl_cn.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [XX]:CN //国家中国填写CN
State or Province Name (full name) []: Guangdong //省
Locality Name (eg, city) [Default City]: Guangzhou //市
Organization Name (eg, company) [Default Company Ltd]: Cheapssl //填写组织或企业名称，如果是个人随便填写一般填写英语或拼音
Organizational Unit Name (eg, section) []: IT //部门
Common Name (eg, your name or your server’s hostname) []: www.cheapssl.cn //这个最重要填写要申请证书的域名
Email Address []: admin@cheapssl.cn //邮箱 Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []: //不用填写回车即可
An optional company name []: //不用填写回车即可

完成后将生成两个文件 www_cheapssl_cn.csr 和 www_cheapssl_cn.key ，打开www_cheapssl_cn.csr ，复制里面所有代码，用于申请证书，保存好 www_cheapssl_cn.key ，安装的时候要用到这个文件。

from:在Linux服务器或VPS上生成CSR(证书请求文件)

refer:

Generate a CSR for Apache with OpenSSL

OpenSSL CSR Creation for Apache

生成CSR证书请求文件

常用Openssl命令

详解https是如何确保安全的？

四月 15, 2016SecurityHTTPS, SSLdotte

Https 介绍

什么是Https

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

Https的作用

内容加密 建立一个信息安全通道，来保证数据传输的安全；
身份认证 确认网站的真实性
数据完整性 防止内容被第三方冒充或者篡改

Https的劣势

对数据进行加解密决定了它比http慢

需要进行非对称的加解密，且需要三次握手。首次连接比较慢点，当然现在也有很多的优化。

出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令，HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control: Public，缓存就会被写到硬盘上。 IE只要http头允许就可以缓存https内容，缓存策略与是否使用HTTPS协议无关。

HTTPS和HTTP的区别

https协议需要到CA申请证书。
http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

http默认使用80端口，https默认使用443端口

下面就是https的整个架构，现在的https基本都使用TLS了，因为更加安全，所以下图中的SSL应该换为SSL/TLS。

下面就上图中的知识点进行一个大概的介绍。

加解密相关知识

对称加密

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

非对称加密

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。

非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。

摘要算法

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
数字签名的过程如下：
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效：
一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
二、数字签名能确定消息的完整性。

注意：
数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

数字证书

为什么要有数字证书？

对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。

数字证书的颁发过程

用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。

证书包含哪些内容

证书颁发机构的名称
证书本身的数字签名
证书持有者公钥
证书签名用到的Hash算法

验证证书的有效性

浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了，认为是危险证书。
对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A，然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的。
证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。

1、2点是对伪造证书进行的，3是对于篡改后的证书验证，4是对于过期失效的验证。

SSL 与 TLS

SSL (Secure Socket Layer，安全套接字层)

SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3.0版本。

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协议作用：

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

TLS比SSL的优势

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

SSL、TLS的握手过程

SSL与TLS握手整个过程如下图所示，下面会详细介绍每一步的具体内容：

客户端首次发出请求

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

客户端需要提供如下信息：

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

服务端首次回应

服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端，这里的随机数是整个过程的第二个随机数。

服务端需要提供的信息：

协议的版本
加密的算法
随机数
服务器证书

客户端再次回应

客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。

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

服务器再次响应

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

后续客户端与服务器间通信

确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

值得特别提出的是：
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。

其他补充

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

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

session的恢复

有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID

session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话

session ticket

客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

目前只有Firefox和Chrome浏览器支持。

总结

https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。

参考文章
数字证书的基础知识
 HTTPS科普扫盲帖
 和安全有关的那些事
 OpenSSL 与 SSL 数字证书概念贴
 基于OpenSSL自建CA和颁发SSL证书
 聊聊HTTPS和SSL/TLS协议
 SSL/TLS协议运行机制的概述
 图解SSL/TLS协议
 大型网站的 HTTPS 实践
 SSL/TLS原理详解
 扒一扒HTTPS网站的内幕
 白话解释 OSI模型，TLS/SSL 及 HTTPS
OpenSSL HeartBleed漏洞原理漫画图解

Jason

简单来说，HTTPS的握手过程就是使用非对称加密的通信过程在客户端和服务端之间协商出一个基于随机数的对称加密密钥，之后的通信过程使用该密钥进行对称加密通信

from:http://www.wxtlife.com/2016/03/27/%E8%AF%A6%E8%A7%A3https%E6%98%AF%E5%A6%82%E4%BD%95%E7%A1%AE%E4%BF%9D%E5%AE%89%E5%85%A8%E7%9A%84%EF%BC%9F/

SSL/TLS协议运行机制的概述

八月 27, 2015SecuritySSL, TLSdotte

互联网的通信安全，建立在SSL/TLS协议之上。

本文简要介绍SSL/TLS协议的运行机制。文章的重点是设计思想和运行过程，不涉及具体的实现细节。如果想了解这方面的内容，请参阅RFC文档。

一、作用

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。

（2） 篡改风险（tampering）：第三方可以修改通信内容。

（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

（1）所有信息都是加密传播，第三方无法窃听。

（2）具有校验机制，一旦被篡改，通信双方会立刻发现。

（3）配备身份证书，防止身份被冒充。

互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。

二、历史

互联网加密通信协议的历史，几乎与互联网一样长。

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。

1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。

TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

三、基本的运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

（1）如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

（2）公钥加密计算量太大，如何减少耗用的时间？

解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

（1）客户端向服务器端索要并验证公钥。

（2）双方协商生成”对话密钥”。

（3）双方采用”对话密钥”进行加密通信。

上面过程的前两步，又称为”握手阶段”（handshake）。

四、握手阶段的详细过程

“握手阶段”涉及四次通信，我们一个个来看。需要注意的是，”握手阶段”的所有通信都是明文的。

4.1 客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

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

（1）支持的协议版本，比如TLS 1.0版。

（2）一个客户端生成的随机数，稍后用于生成”对话密钥”。

（3）支持的加密方法，比如RSA公钥加密。

（4）支持的压缩方法。

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

4.2 服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

（1）确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2）一个服务器生成的随机数，稍后用于生成”对话密钥”。

（3）确认使用的加密方法，比如RSA公钥加密。

（4）服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

4.3 客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1）一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

至于为什么一定要用三个随机数，来生成”会话密钥”，dog250解释得很好：

“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

4.4 服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。

（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

五、参考链接

MicroSoft TechNet, SSL/TLS in Detail
Jeff Moser, The First Few Milliseconds of an HTTPS Connection
[中]http://www.infoq.com/cn/articles/HTTPS-Connection-Jeff-Moser
Wikipedia, Transport Layer Security
StackExchange, How does SSL work?
图解SSL/TLS协议http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

from:http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

如何理解谷歌浏览器的安全警告信息

八月 18, 2015CA, SecurityHTTPS, SSLdotte

最近如果使用Chrome访问国内的很多网站的时候，比如exmail.qq.com, 你可能会注意到这样一个对话框，这个是什么意思？访问链接没有私密性吗? 等等，这里好像有点不对，网页私密性到底是个啥，为啥会提醒我这个问题，我不是已经输了密码登录了嘛？事情要从头说起。

我上个邮箱，连私密性都没有了，那里面的照片应该怎么办，以前修电脑没有私密性，现在连上网都没有私密性，难道我又要红了？

一、HTTPS (安全超文本协议）怎么来的？

1997 年 CERN发明HTTP 协议并用于万维网的时候，仅仅是为了在学术界内部做一个共享数据的平台, 并没有想到太多传输中的安全性。毕竟当年网络规模非常小，而计算机以及昂贵的网络设备并不是每个人都可以买得起的。

他们当然没有料到之后万维网居然成了一个信息传递的通用平台，一帮人甚至丧心病狂地在上面做起了Web电子邮箱、网络银行一类的服务。这类服务对安全性和私密性的要求都非常严格，因为基本上没有人希望自己的银行密码，私人的邮件在传输中被第三方看到。

所以问题就来了， HTTP 是明文传输的。 HTTP倒是支持密码认证，只是不巧的是，密码也是明文传的。

针对这种情况，在网景一帮科学家，特别是 Dr. Taher Elgamal （号称SSL 之父）的努力下， HTTPS 横空出世了。

HTTPS 里面，所有传输的数据都是加密过的，于是第三方无法在数据的传输过程中获得任何有用的数据，数据传输中的私密性自然得到了保证。

至少当初设计的目的是这样子。

HTTPS 并非是一个全新的协议，其实是在 HTTP的基础上，加了 SSL （安全套接字）或者是后来的 TLS (传输安全协议)。 SSL/TLS 工作在 HTTP 之下, 负责加密所有传输的数据。

说个题外话，当时不仅仅是 HTTP，众多的互联网上层协议，即应用层协议，STMP 电子邮件协议一类，大多都是明文传输的。而移动互联网或
者其他网络，都是基于一些标准的协议，就是TCP/IP协议簇。早期时候，这些协议是由互联网领域专家联合制定的，就像现在制定法律的过程一样。而经过实
际的验证，其不严谨性渐渐被发现，于是人们在此前的基础上进行不断更新，SSL/TLS就是这样出来的。 SSL/TLS
由于是工作在TCP层和应用层之间，它可以加密任何应用层协议，包括STMP一类。从这个角度说来，网景对互联网的贡献其实是非常深远的。

HTTPS 使用非对称算法交换密钥，这个也是一个非常精巧的算法，有兴趣的同学可以点击这里了解下，号称是20世纪最重要的算法之一。

HTTPS 除了解决加密问题以外，还需要还解决另外一个问题：网站真实身份鉴别

比如，如果你上招行网站，你怎么知道你上的就是招商银行网站而不是一个做得和招商银行一模一样的钓鱼网站呢？

这个其实和现实生活中如何鉴定一个长的像警察并且突然站到你面前要你交罚款的人是否是真正的人民警察是一个场景。

”警官证可以给我看看吗，谢谢！“

HTTPS 用的是同一种方法，它要求每一个使用这个协议的网站从专业的第三方机构申请一个数字证书，数字证书中包括网站的域名，所有者等等（当然也包括公钥，这里不详细展开协议细节了）。

这个数字证书其实就相当于现实中的警官证。

在访问这个网站的时候浏览器会对证书做一次检查，而这个对话框，就是检查的结果。

我们来看看这个对话框内容是个什么鬼。

二、如何鉴别你是警察？因为警官证也有可能是假的。

第一个：

该网站的身份验证已经通过GeoTrust SSL CA–G2的验证，但没有公开审核记录。该网站的安全设置已过期，可能导致日后的Chrome 版本无法安全访问该网站。

刚才有提到证书是由专业机构颁发的，不过，

－专业机构就没有坏人了嘛。

－证书就不会被人偷吗。

－专业机构被骗了怎么办。

事实上，荷兰专业机构(DigiNotar)甚至被入侵过一次，丢了好几百个证书，你可以自行脑补一下有人潜入公安部自己办了几百个警官证是一个多么壮观的场景。

于
是，IETF在2013年启动了一个叫做certificate-transparency的开源项目，把所有已知的合法证书做了一个白名单，浏览器在验
证证书的时候同时也会去查看这个证书是不是在白名单里面。如果不在的话，就会告知用户这个证书找不到记录，于是，有可能是假或者是被盗的证书。

但是，这里有一个致命的问题：

到目前为止，这个还只是一个试验性项目，而这个世界上那么多的网站，你白名单得过来嘛。

（注意：已经没有警示标志）

比如上图所显示的，其实也没有审核纪录，不过警告的标示去掉了。说明谷歌其实自己也知道目前白名单的覆盖很差，一般找不到记录，并不会加上确切的警告标示。所以，目前你可以忽略它。

关键在第二个：

本网站采用较弱的安全配置（SHA-1签名），所以你的连接可能不是私人的。

这个就比较有意思了。

还是那个警官证的问题。要搞一个警官证除了去偷/骗/潜入公安部自己做一个真的以外, 你还可以做个假的嘛。

对于数字证书来说，最重要的鉴别真假的部分是数字签名，而鉴于数字证书一般不小，不可能对每个字节都签一次名，一般来说是对数字证书的一个哈希值进行签名。

如果你不知道哈希值是什么，我给你打个比方。如果你是一个数字证书，那你的照片就是你的哈希值。

它包含下面2个条件：

－通过合适的手段，可以从你产生你的照片，但是没法从照片产生你。意思是，先有你，才能有照片。

－只有你可以精确的产生你的照片，别人都不行。你就是唯一的，你的特征是别人没有的。

所以如果想检查一个人的警官证，只需要看看照片能不能对上人(哈希值符合)，照片上面的骑缝章对不对(数字签名)。但是这个骑缝章只需要盖在照片上，而不需要盖在警官兄的脸上。当然我知道这个比喻有非常多学术上的不严谨性，不过这个是我目前能找到最容易理解的比喻之一了。

数字证书中， SHA-1就是一种常见的哈希算法。可以像照相机一样，给你的数字证书生成一个唯一值（照片）。

只是这个算法有一个问题。这个算法这个函数由于设计时间早，强度太差，导致有可能用两个不同的数字证书可能会生成同样一个值。

这个就像如果你有一个照身份照的照相机，不过这个神奇的照相机拍的太模糊，以致于通过特殊的设定，可以用另外一个人照出和真实警官一模一样的照片。恭喜你，如果你发现了这个设定，你就可以大规模的制作套牌警官证了。

这种现象在哈希函数中被称为是“碰撞”。

对于SHA-1 算法如果要找到这个“特殊的设定”大概需要2的74次方个操作，（也有论文指出，只需要2的61次方个操作即可完成）这个在SHA-1发明的时候是不可想象，不过其实在现在也是不可行的。只是按照现在计算机的发展速度 2018 年左右使用价格合适服务器集群理论上就可以破解（可以参考这里）：

”A
collision attack is therefore well within the range of what an
organized crime syndicate can practically budget by 2018, and a
university research project by 2021。“

（”因此，在一个有组织犯罪集团的范围内，一次碰撞攻击的实际预算是2018，而一个大学的研究项目是2021“）

于是，Chrome 认为使用SHA-1的哈希函数都是潜在不安全的，于是会对所有使用SHA-1的网站证书提出警告，督促所有使用SHA-1的网站换为SHA-2。

不过注意，仅仅是潜在不安全，目前还没有可行可靠的SHA-1碰撞算法出现。

所以，这些网站暂时是安全的，不过也希望站长们多多提高安全意识，因为SHA-1已经非常接近可以被“破解”边缘。很有可能会出现以上情况：被人找到碰撞算法或者说被破解，从而制作虚假警官证。

如果要详细的证书设置以去除这个警告的步骤，可以参考这里（点击进入链接）

因为工作原因——欧朋Opera是Chromium安全组成员，所以我对这个内情比较了解。有兴趣可以去看看讨论组里面的撕逼贴, 截个屏放在这里：

from: http://www.techug.com/google-browser